Dear Marc Thank you for your reply. Your answer causes some more questions: Do you think it is better to use processes than threads? What I would like to do is the following: Assume two clients connected to a server and asking the server to do something. However, one client has to wait until the server has processed the request of the second client. Then the second client can resume. What is the best way to this? As far as I understand from some reading, the parent process can fork() a child process and can wait() for the child process to complete? But is it also possible that one child process can wait for another child process? Or do I misunderstand something? Regarding Go4, I tried to study the code, but it is wrapped into so many Go4 classes, so it is hard to understand, especially since it is not possible yet to download the source code. Do you mean that the server should start a separate TServerSocket for every client which connects to it? Thank you in advance Best regards Christian Marc Hemberger wrote: > Hi Christian, > > cstrato@EUnet.at wrote: > >> Dear Rooters >> >> Maybe this is a good opportunity to ask some questions about >> TThread: >> >> 1, In which cases would it be recommended to use class TThread? >> > If you can not think of some use for threads in your application, then > you don't need them ;-) But I think, if you want to see some of the > uses of threads in general, take a look at Valeris 'Literature List' > in one of his previous mails: > > > TrollTech Web site http://doc.trolltech.com/2.3/threads.html says: > > " . . . This document is intended for an audience that has knowledge > > and experience with multithreaded applications. Recommended reading: > > a.. Threads Primer: A Guide to Multithreaded Programming > b.. Thread Time: The Multithreaded Programming Guide > c.. Pthreads Programming: A POSIX Standard for Better > Multiprocessing (O'Reilly Nutshell) > d.. Win32 Multithreaded Programming > > Take also a look at http://go4.gsi.de. > >> 2, Support for Dual-Processor machines: >> Sorrowly, I do not have such a machine :-(, but for interest: >> If you write programs in root and want your program to take >> advantage >> of a dual-processor machine: >> What is the best way to achieve this goal? >> Do you need to use PROOF? >> Would TThread support dual-processors? >> As far as I understand, Mach (MacOSX) threads support SMP. Does >> root TThread support this? What about Linux? Does not WinNT also >> support threads? >> > Dual processor machines are a bit a different topic. The simplest way > of exploiting two CPUs is the use of two processes, which each use one > processor. They act independently, so they are really independent. > > When you want to use only one process, then you might want to use > threads within a single process. But then, sharing resources in one > process so that they can be used within different threads can and will > cause an overhead, which reduces the performance of your program may > be a lot. > > Most of the SMP implementations are worked out quite well (even for > Linux;-), so the OS can deal with it in general. Cache coherency is > causing troubles, but works well. > > Don't expect too much of a multiprocessor machine when you use > threads. What you will get is at first trouble, then more trouble and > in the end perhabs a gain of 50% in performance, but never the > expected 100% (as you would have with two didtinct processes). At > least what my experience tells me (from Linux, HP, Sun and AIX > multi-processor machines). > >> 3, The tutorial spyserver.C shows how a TServerSocket can handle >> requests from two or more clients. No threads are necessary. >> In which cases would threads be necessary? >> Could this tutorial be expanded to show how to use TThreads? >> > Hmm, the server uses one socket, different clients attach to this port > and "spy" for histograms. Imagine the case, that you want to use > different sockets ... Check for the Go4 page, which does something > like that: a per-client connection in a thread, which will never/not > block, when nothing comes. > >> Thank you. >> >> Best regards >> Christian >> > Greetings, > > Marc > > >> ---------------------------------- >> C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a >> V.i.e.n.n.a, A.u.s.t.r.i.a >> >> -- >> Dr. Marc Hemberger >> /\_/\ >> ( o.o ) >> > ^ < >> |\ _,,,---,, EMBL >> ZZZzz /,`.-'`' -. ;-;;,_ C&N Group >> |,4- ) )-,_. ,\ ( `'-' Meyerhofstr. 1 >> '---''(_/--' `-'\_) 69117 Heidelberg >> Germany privat: >> Marc.Hemberger@embl-heidelberg.de >> MHemberger@csi.com >> >> ** Disclaimer: My views/comments/beliefs, as strange as they >> are, are my own.** >>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:46 MET