Thread killing - I know I know!
Roger Heathcote
usenet at technicalbloke.com
Fri May 16 11:40:49 EDT 2008
Hello everyone, this is my first post so hello & please be gentle!
Despite many peoples insistence that allowing for the arbitrary killing
of threads is a cardinal sin and although I have no particular threading
problem to crack right now I remain interest in the taboo that is thread
killing. The real world and it's data are messy and imperfect and I can
think of several scenarios where it could be useful to be able to bump
off a naughty thread, especially when using/testing unstable 3rd party
modules and other code that is an unknown quantity.
With this in mind I am experimenting with a set of threading subclasses
that would permit timeouts and the manual killing of threads. I'm trying
to evaluate how robust such a scheme can be made and what the
limitations would be in practice.
So far I can seemingly murder/timeout pure python threads that are stuck
blocking for input and stuck in infinite loops but I'm guessing there
are many more awkward cases. What I'm looking for are examples of
code/modules that can get stuck in dead ends or might otherwise be
problematic to terminate.
In particular I'd be interested to see if I could kill a non-returning c
module. Of course naturally no one wants to be publishing buggy modules
and the like so I am having trouble finding examples of misbehaving c
code to explore further. I figure I could learn how to write c modules
for python but, while it's something I'd like to know someday, I'm
guessing that will be too long to fit into the immediate future :/
Consequently if anyone has detailed knowledge of what is and isn't
fundamentally possible in the world of thread culling, or if you can
point me to some gnarly/non-returning thread code to test with I would
be forever grateful.
Oh yes, I'm working primarily with 2.5 on XP however I have access to
linux & OSX boxen and I'd be interested to learn about problematic
thread code for either of those platforms as well.
Thanks for reading,
Roger Heathcote - www.technicalbloke.com
More information about the Python-list
mailing list