How to force a thread to stop

[Gerhard Fiedler]

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