On Thu, Jul 15, 2004 at 10:35:08AM -0400, D. Richard Hipp wrote: > Unsolicited advice: Your best bet is to run no more than one thread > in each process. If you need multiple threads, create multiple > processes to contain them. Writing applications with multiple > threads in the same address space is like smoking cigarettes: it > gives you a buzz, but in the long run it is deadly. Just say "no".
This has some important truth to it, but is a vast oversimplification. Multiple threads vs. multiple process is NOT an apples to apples to comparison. The correct comparison is between: 1. Multiple threads, and related thread syncronization tools. 2. Multiple processes, plus shared memory, and related syncronization tools. If you don't really need 2., then yes, you likely don't really need 1. either, you probably have other options - message passing, one single process using non-blocking IO, etc. Some multi-threaded environments, like AOLserver or the Tcl Threads Extension, purposely create an environment where each thread has its own higher level (Tcl) interpretor, plus good APIs for explicitly and safely accessing data in shared process-global memory. This model unfortunately tends to make the threads rather heavy-weight (although there are ways around that) but overall it works very nicely. Note that a Tcl-like or AOLserver-like threading model also essentially makes 1. and 2., above, indistinguishable to the typical application programmer. Threads vs. process shared memory becomes essentially a changeable implementation rather than a fixed design question. You only ever even need to think about the difference if you're writing (lower level) C code, and even then the more powerful C APIs in an AOLserver-like environment make things easier than just writing C code from scratch using the POSIX APIs. There are various other arguments in favor of the very light-weight threads really-do-share-everything models, but I lack any real hands-on experience there. Mabye they're bogus, I don't know. Btw, internally, the Linux kernel takes neither the traditional Processes nor the Threads side of things. It draws no hard line between the two camps, but instead has, I'm told, some sort of ability to specify in detail just what parts of any particular flavor of Process/Thread entity are shared, and which are kept private. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
