Carl Banks <pavlovevide...@gmail.com> writes: > > > 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 think I mis-read your suggestion. I thought you meant to query another thread before acquiring a lock. Anyway, the usual reason to want to kill a thread is that it's become unresponsive for some reason, while holding onto some resource like a lock or a bound socket. This would be in the category of fault recovery from conditions that weren't expected ahead of time. Another situation is when you want to just stop the program altogether, similar to kill -9'ing it, with no attempt to shut down gracefully. Kind of a global ctrl-C. Right now there is no way to do that for a multithreaded program except by literally sending a process kill, which is pretty ugly. -- http://mail.python.org/mailman/listinfo/python-list
