Killing a thread
Diez B. Roggisch
deets at nospam.web.de
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