On 2006-07-25 13:55:39, Carl J. Van Arsdall wrote: > I'd be all for using processes but setting up communication between > processes would be difficult wouldn't it? I mean, threads have shared > memory so making sure all threads know the current system state is an > easy thing.
I'm not sure about that. Sharing data between threads or processes is never an easy thing, especially since you are saying you can't trust your module coders to "play nice". If you can't trust them to terminate their threads nicely when asked so, you also can't trust them to responsibly handle shared memory. That's exactly the reason why I suggested processes. > With processes wouldn't I have to setup some type of server/client > design, where one process has the system state and then the other > processes constantly probe the host when they need the current system > state? Anything else is bound to fail. You need to have safeguards around any shared data. (A semaphore is a type of server/client thing...) At the very least you need to prevent read access while it is updated; very rarely this is an atomic action, so there are times where the system state is inconsistent while it is being updated. (I don't think you can consider many Python commands as atomic WRT threads, but I'm not sure about this.) IMO, in the situation you are describing, it is an advantage that data is not normally accessible -- this means that your module coders need to access the data in the way you present it to them, and so you can control that it is being accessed correctly. Gerhard -- http://mail.python.org/mailman/listinfo/python-list
