Dear Joern, just a question concerning your remark: Why should the TApplication "know" about sockets and their creation location (threads or main process)? On basis of the operating system, this is completely transparent to any application. It's just file descriptors. If it makes really a difference, then it is the problem of the OS. A FIN_WAIT state on a TCP connection may by caused by several reasons (e. g. some problems in closing the socket in the right order: server first/second, client second/first, still some valid data on the descriptor, ...). The OS simply does e. g. not know if there is still a valid end-point on one of the sides. In my application, I create/accept/open/close/delete TServerSockets and TSockets in a/many TThread/s. And this works for me. I'm currently still using Root 3.01/05 (but only because the newer Root has some problems with some of my Templates) on a Linux 2.2.16 machine. Another point: why should the TMonitor::Select() work not properly? It's just the same remark as above: it's just file descriptors. And last but not least: locking everything around a Streamer and any object instatiation is a really hard performance killer. In our Client/Server Monitoring Application we rely heavily on all the features above mentioned, and I don't see anymore the limitations you mentioned. Just my 5 cents. Greetings, Marc For the historically interested some explanation. Joern and me were dealing on this topic "tout ensemble" some 2 years ago at GSI and Go4, but now I'm working in industry on something completely different, but still using Root: Client/Server, multi-threaded/multi-tasking, CORBA, GUI (Root/Qt), DB access all mixed together. So, some of my current understanding and knowledge is due to my own findings/learning curve (after my time at GSI). -> -----Original Message----- -> From: Adamczewski Dr. Joern [mailto:J.Adamczewski@gsi.de] -> Sent: Friday, October 26, 2001 3:03 PM -> To: 'Volker Hejny'; Roottalk -> Subject: AW: [ROOT] TThread: What can be done in a thread? -> -> -> Hi Volker! -> -> > can one do socket communication in a TThread, i.e. use TSocket? -> Yes, you can use TSockets in a TThread. We use it intensively for -> the Go4 framework http://go4.gsi.de/ (Go4TaskHandler library). -> -> However, you get into trouble if you try to _create_ a TServerSocket -> from within a running thread; a socket accepted by this -> serversocket instance might not be closed properly on deletion -> of the TSocket instance (such was my experience when I tested -> it with previous root versions). The linux tcp were not -> cleaned up after finishing the root session and kept in a FIN_WAIT -> state for hours! -> This is probably caused by the fact that the root socket instances -> are managed by the root TApplication::InnerLoop(), which -> does not know about sockets created in threads. -> -> Therefore it is better to create root socket connections -> outside the threads, e.g. in the ctor of a class, or in -> a root TTimer (i.e. in the scope of the TApplication loop). -> The existing TSocket can then be passed to a thread which -> works on it. -> -> > If yes, what actions have to be performed in locked state? I -> > tried to run the client-server example from the tutorials -> > with the server code in a TThread. The hclient.C was still -> > executed in two different root sessions as macro. -> > The whole thing starts fine, but after a while the root session -> > running the server process completely hangs. -> Do you still use the TMonitor::Select in the hserver.C? -> I guess this could be crucial, -> since the method invokes the gSystem->InnerLoop(), which can not -> be expected to work in several threads! -> -> Additionally, if you use root TMessage transport, be aware -> that here each TSocket::Receive(TMessage*) and TMessage::ReadObject -> creates objects and uses the root streamer, respectively. -> In general, I would suggest to TThread::Lock() all streamer usages -> and object instantiations in the different threads, if possible. -> However, you must not lock TSocket::Receive... -> -> -> Hope this helps, -> best regards -> Joern -> -> -> -> ///////////////////////////////////////////////////////////////////// -> // Dr. J"orn Adamczewski (J.Adamczewski@gsi.de) // -> // GO4 project team Tel: +49-06159-71-2554 // -> // Datenverarbeitung & ExperimentElektronik FAX: +49-06159-71-2986 // -> // Ges. f. SchwerIonenforschung, Planckstr.1, D-64291 Darmstadt // ->
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET