How to kill threading.Thread instance?

Fuzzyman fuzzyman at
Sun Sep 21 23:51:02 CEST 2008

On Sep 21, 4:04 pm, Fredrik Lundh <fred... at> wrote:
> Diez B. Roggisch wrote:
> >> I wonder why something like myThread.exit() or myThread.quit() or
> >> threading.kill(myThread) can't be implemented?
> >> Is something like that present in Python 3000?
> > Not that I'm aware of it (which doesn't mean to much though).
> > However I *am* aware of the bazillions discussions that have been held
> > over this here - and the short answer is: it is a generally very bad
> > idea to terminate threads hard, as it can cause all kinds of corruption.
> the problem is that you have no idea what the thread is doing, so just
> killing it dead it may make one big mess out of the application's
> internal state; see e.g. this post
>    That's wise ;-)  Stopping a thread asynchronously is in /general/ a
>    dangerous thing to do, and for obvious reasons.  For example, perhaps
>    the victim thread is running in a library routine at the time the
>    asynch exception is raised, and getting forcibly ejected from the
>    normal control flow leaves a library-internal mutex locked forever.
>    Or perhaps a catch-all "finally:" clause in the library manages to
>    release the mutex, but leaves the internals in an inconsistent state.
> which links to a FAQ from Sun on this very topic:
> (note that Java releases all mutexes when a thread is killed, but that's
> not much better, as the FAQ explains)
> so as usual, the right thing to do is to do things in the right way.
> </F>

Often you know terminated a thread would be perfectly safe - and not
being able to is very frustrating - particularly if your calculation
is coarse grained and there is no convenient point to regularly poll
for a stop signal.

.NET solves the 'you might interrupt important stuff' by guaranteeing
that an asynchronous ThreadAbortException won't be raised inside a
finally block.


More information about the Python-list mailing list