How to kill threading.Thread instance?

[dmitrey]

hi all,
Is there a better way to kill threading.Threa d (running) instance than
this one

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496960

(it's all I have found via google).

BTW, it should be noticed that lots of threading module methods have
no docstrings (in my Python 2.5), for example _Thread__bootst rap,
_Thread__stop.

Regards, D.

[Diez B. Roggisch]

Re: How to kill threading.Threa d instance?

dmitrey schrieb:

hi all,
Is there a better way to kill threading.Threa d (running) instance than
this one

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496960

(it's all I have found via google).
>

Nope. There might be other ways technically, but none of them falls into
a "better"-classification.

Diez

[Fredrik Lundh]

Re: How to kill threading.Threa d instance?

dmitrey wrote:

BTW, it should be noticed that lots of threading module methods have
no docstrings (in my Python 2.5), for example _Thread__bootst rap,
_Thread__stop.

things named _Class__name are explicitly marked private by the
implementation (using the "__" prefix).

using them just because you can find them via "dir" is a really stupid
idea. (and, as noted in the comment section to the recipe, the "stop"
method flags a thread as stopped, it doesn't stop it.)

</F>

[dmitrey]

Re: How to kill threading.Threa d instance?

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?
Regards, D.

[Diez B. Roggisch]

Re: How to kill threading.Threa d instance?

dmitrey schrieb:

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.

Systems like Java discourage the use of the available methods for that
as well. And I for example once worked with Qt3-threads, what allow for
this kind of operation - and killed my CORBA-ORB running in the same
process by terminating the thread hard.

Google a bit in this NG to find the discussions & reasons.

Diez

[Fredrik Lundh]

Re: How to kill threading.Threa d instance?

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

http://mail.python.org/pipermail/python-list/2006-August/400256.html

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:

http://java.sun.com/j2se/1.3/docs/guide/misc/threadPrimitiveDeprecation.html

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

[Fuzzyman]

Re: How to kill threading.Threa d instance?

On Sep 21, 4:04 pm, Fredrik Lundh <fred...@python ware.comwrote:

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
>
   http://mail.python.org/pipermail/pyt...st/400256.html
>
   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:
>
http://java.sun.com/j2se/1.3/docs/gu...itiveDeprecati...
>
(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 ThreadAbortExce ption won't be raised inside a
finally block.

Michael

http://www.ironpythoninaction.com/

[Antoon Pardon]

Re: How to kill threading.Threa d instance?

On 2008-09-21, Fredrik Lundh <fredrik@python ware.comwrote:

Diez B. Roggisch wrote:
>

>>I wonder why something like myThread.exit() or myThread.quit() or
>>threading.kil l(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
>

http://mail.python.org/pipermail/python-list/2006-August/400256.html

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

http://java.sun.com/j2se/1.3/docs/guide/misc/threadPrimitiveDeprecation.html

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

Why not let the programmer make the call whether killing the thread dead
is the right thing or not. Maybe the programmer has a pretty good idea
about what the thread can possibilbly be doing and knows that killing it
won't produce a mess.

Sure caution people to be very carefull when they are thinking about
doing something like this. Just as people are generally adviced to
use Queues when doing multithreading. But that is no reason to
disallow certain kind of actions.

--
Antoon Pardon