John Henry wrote: > > > > Carl, > > OS writers provide much more tools for debugging, tracing, changing > > the priority of, sand-boxing processes than threads (in general) It > > *should* be easier to get a process based solution up and running > > andhave it be more robust, when compared to a threaded solution. > > > > - Paddy (who shies away from threads in C and C++ too ;-) > > That mythical "process" is more robust then "thread" application > paradigm again. > > No wonder there are so many boring software applications around. > > Granted. Threaded program forces you to think and design your > application much more carefully (to avoid race conditions, dead-locks, > ...) but there is nothing inherently *non-robust* about threaded > applications.
Indeed. Let's just get rid of all preemptive multitasking while we're at it; MacOS9's cooperative, non-memory-protected system wasn't inherently worse as long as every application was written properly. There was nothing inherently non-robust about it! The key difference between threads and processes is that threads share all their memory, while processes have memory protection except with particular segments of memory they choose to share. The next most important difference is that certain languages have different support for threads/procs. If you're writing a Python application, you need to be aware of the GIL and its implications on multithreaded performance. If you're writing a Java app, you're handicapped by the lack of support for multiprocess solutions. The third most important difference--and it's a very distant difference--is the performance difference. In practice, most well-designed systems will be pooling threads/procs and so startup time is not that critical. For some apps, it may be. Context switching time may differ, and likewise that is not usually a sticking point but for particular programs it can be. On some OSes, launching a copy-on-write process is difficult--that used to be a reason to choose threads over procs on Windows, but nowadays all modern Windows OSes offer a CreateProcessEx call that allows full-on COW processes. In general, though, if you want to share _all_ memory or if you have measured and context switching sucks on your OS and is a big factor in your application, use threads. In general, if you don't know exactly why you're choosing one or the other, or if you want memory protection, robustness in the face of programming errors, access to more 3rd-party libraries, etc, then you should choose a multiprocess solution. (OS designers spent years of hard work writing OSes with protected memory--why voluntarily throw that out?) -- http://mail.python.org/mailman/listinfo/python-list