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 -- http://mail.python.org/mailman/listinfo/python-list
