How to kill threading.Thread instance?
fuzzyman at gmail.com
Sun Sep 21 23:51:02 CEST 2008
On Sep 21, 4:04 pm, Fredrik Lundh <fred... at pythonware.com> 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.
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
More information about the Python-list