John, I cannot resist on this. Sorry, but I cannot resist at all. Having been involved in a number of open source projects with quite different views on threads, and read peoples comments, and seen what happens, and written code with hundreds of active threads, I want to put my bit in..
On Tue, 14 Nov 2006, John Carter wrote: > > elf, mmap & fork, why we don't need threads. > > select & poll, another reason you don't need threads. > Not everyone agrees - threads are inevitable. One very good arguement is found in http://www.gotw.ca/publications/concurrency-ddj.htm I will put it differently. Asterisk is a well known open source project, which started of with a clear desire not to use threads. You can read the comments - threads take ages to switch between. The IAX part of it is written this way, with one thread handling all incoming and outgoing IAX packets. This works fine for when there is one or two active IAX calls. However, in a server application, where there are lots (tens to hundreds) of active calls, what happens? When someone registers, and registrations are handled by a database, all active calls have a momentary glitch in audio. So, the code was modified to add a new thread to handle registrations. It is not possible to totally abstain from using threads. openh323 is a well known open source voip project which has been around for longer than asterisk with a phenomenal install base. If you pick up an ADSL box with some sort of H.323 proxy in it, a reasonable guess is to say it is using openh323 code. They use multiple threads per call, (one for incoming audio, one for outgoing audio, a couple for control etc) and in a server application with hundreds of active calls one runs into OS limitations of the number of calls. Well, they added thread aggregation, where one thread handles the audio stream for multiple calls. Now here is the problem. Suppose someone takes the openh323 library, with thread aggregation enabled, and adds some more work to some of those system threads? Easy answer, multiple calls will experience momentary outages in call control or the audio stream. Who gets the blame for these outages ? - the library - or the user's code? Using poll and select to find out what file descriptor has data ready seems like a duplication of the work in the kernel. The kernel already knows what file descriptor has data ready. Why not let the kernel switch control to the thread waiting for data on a particular file descriptor? As a programmer, one should avoid duplication of work. If the kernel already knows where the data is, why not let the kernel switch execution to handle that work? Which would be easier than doing the switching myself by multiple calls to select to find out where work is to be done. I have debugged multi threaded applications and found it a challenge. Initial versions of the code crashes (no supprise, it is C++), and I was left with a core dump. Open the executable and core dump up in a gdb based debugger, and one of three things happen. 1) It shows clearly where the segfault happened, and I can look at the backtrace of the other threads. 2) It takes ages and ages to load everything, and then some more time, and then gdb stops and says something like , "segfault, cannot continue". End of theat debugging session. 3) Eventually, gdb does load up, and it says, "initial frame selected, you cannot go up, you cannot go down". In other words, gdb cannot shows me where the segfault happened. My colleagues with very extensive linux and lots of MSVC experience report that threads are quite a bit easier to debug on windows, with a GUI to quickly move around the various backtrace of each active threads. Some say threads are slow to do context switching. That might have been true last century. Now that we have real time kernels (2.6.18) with microsecond response times, on machines running multiple gigahz clock speed, context switching will be much faster. My personal view that when I hear developers say "threads are bad" is that the developer is actually saying a) gdb is a poor tool for debugging threads b) threads are hard to debug under linux c) the developer has never been forced to learn and undertand threads, so (out of laziness perhaps) never wants to use threads. I have found that if you are forced to debug code on linux, add these options to your compile line -g3 -ggdb -O0 They help heaps. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
