On Apr 26, 3:03 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Carl Banks <pavlovevide...@gmail.com> writes: > > Which is "communicating with the rest of the program periodically". > > > Presumably you have to protect objects to share them? There you go: > > anytime you try to acquire a lock have the thread check to see whether > > to abort. > > Normally, acquiring a lock doesn't require running code in other > threads, at least in the uncontended case. If you have to switch > threads twice in order to acquire a lock, your implementation could > use some improvement.
Come on, you're just making stuff up. How the *hell* do you get switching threads twice out of that? I'm saying that if threads have to synchronize data, then it's no big deal to have the thread check a flag over whether to terminate when synchronizing. Take a look at this recipe for an example: http://code.activestate.com/recipes/576461/ That concept, I say, can be applied to any thread that shares data with the main thread, with any sort of regularity, even if it's doesn't use queues specifically. The only time it's any trouble to notify a thread to terminate is when that thread's running code that's not aware it's in a threaded app (which implies that it's not sharing any data, aside from read-only). But since it's not communicating with another threads you might as well run it in another process; communication overhead is not going to be a big deal in that case. Carl banks -- http://mail.python.org/mailman/listinfo/python-list
