Killing a thread

Diez B. Roggisch deets at
Sat Jun 10 12:09:23 CEST 2006

> 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.


More information about the Python-list mailing list