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.
In this particular case, the OP (in a different thread) mentioned that his application will be extended by random individuals who can't necessarily be trusted to design their extensions correctly. In that case, segregating the untrusted code, at least, into separate processes seems prudent. The OP also mentioned that: > If I have a system that has a large area of shared memory, > which would be better? IMO, if you're going to be sharing data structures with code that can't be trusted to clean up after itself, you're doomed. There's just no way to make that scenario work reliably. The best you can do is insulate that data behind an API (rather than giving untrusted code direct access to the data -- IOW, don't use threads, because if you do, they can go around your API and screw things up), and ensure that each API call leaves the data structures in a consistent state. -- JK -- http://mail.python.org/mailman/listinfo/python-list
