[EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > > John Henry wrote: > > > 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 > > Also, race conditions and deadlocks are equally bad in multiprocess > solutions as in multithreaded ones. Any time you're doing parallel > processing you need to consider them. >
Only in the sense that you are far more likely to be dealing with shared resources in a multi-threaded application. When I start a sub-process, I know I am doing that to *avoid* resource sharing. So, the chance of a dead-lock is less - only because I would do it far less. > I'd actually submit that initially writing multiprocess programs > requires more design and forethought, since you need to determine > exactly what you want to share instead of just saying "what the heck, > everything's shared!" The payoff in terms of getting _correct_ > behavior more easily, having much easier maintenance down the line, and > being more robust in the face of program failures (or unforseen > environment issues) is usually well worth it, though there are > certainly some applications where threads are a better choice. If you're sharing things, I would thread. I would not want to pay the expense of a process. It's too bad that programmers are not threading more often. -- http://mail.python.org/mailman/listinfo/python-list