> Are there any plans in the future to add the capability to kill threads > from the outside? Better yet, an interruptable thread so instead of > using a polling loop you could send a DIE_THREAD_DIE signal or > something. I think at present its not possible (or a really bad idea) > to put signal handlers in threads. Anyone have thoughts on this?
Thought - many people. And it seems to be a bad idea. I once used PyQt QThreads, because they allowed me to do it. Which immediately crashed my omniORB ORB when terminating a thread. I didn't investigate why, but I guess you are pretty much on your own releasing resources and the like. And that gets very tedious very fast. > I toyed with another idea (this is a big problem for me), but I noticed > that each python thread spawns a new interpreter. If python is doing > this, I would think that each thread could be associated with PIDs or > something. I haven't thought about it too much, its a little to > crazy/brute force for me, but I thought i'd throw it out there so you > guys could tell me if that one is a little too far fetched. Python uses the underlying OS thread implementation. It does _not_ spawn new threads. I guess you are using a LINUX that lists individual threads as subprocesses. But that is a n implementation detail that can be configured away AFAIK. Or at least it doesn't happen on _all_ linuxes. So you're out of luck there, too. Diez -- http://mail.python.org/mailman/listinfo/python-list
