John Henry wrote: > If you're sharing things, I would thread. I would not want to pay the > expense of a process.
This is generally a false cost. There are very few applications where thread/process startup time is at all a fast path, and there are likewise few where the difference in context switching time matters at all. Indeed, in a Python program on a multiprocessor system, process are potentially faster than threads, not slower. Moreover, to get at best a small performance gain you pay a huge cost by sacrificing memory protection within the threaded process. You can share things between processes, but you can't memory protect things between threads. So if you need some of each (some things shared and others protected), processes are the clear choice. Now, for a few applications threads make sense. Usually that means applications that have to share a great number of complex data structures (and normally, making the choice for performance reasons means your design is flawed and you could help performance greatly by reworking it--though there may be some exceptions). But the general rule when choosing between them should be "use processes when you can, and threads when you must". Sadly, too many programmers greatly overuse threading. That problem is exacerbated by the number of beginner-level programming books that talk about how to use threads without ever mentioning processes (and without going into the design of multi-execution apps). -- http://mail.python.org/mailman/listinfo/python-list
