How to kill threading.Thread instance?

Discussion in 'Python' started by dmitrey, Sep 21, 2008.

  1. dmitrey

    dmitrey Guest

    hi all,
    Is there a better way to kill threading.Thread (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__bootstrap,
    _Thread__stop.

    Regards, D.
     
    dmitrey, Sep 21, 2008
    #1
    1. Advertising

  2. dmitrey schrieb:
    > hi all,
    > Is there a better way to kill threading.Thread (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
     
    Diez B. Roggisch, Sep 21, 2008
    #2
    1. Advertising

  3. dmitrey wrote:

    > BTW, it should be noticed that lots of threading module methods have
    > no docstrings (in my Python 2.5), for example _Thread__bootstrap,
    > _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>
     
    Fredrik Lundh, Sep 21, 2008
    #3
  4. dmitrey

    dmitrey Guest

    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.
     
    dmitrey, Sep 21, 2008
    #4
  5. 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
     
    Diez B. Roggisch, Sep 21, 2008
    #5
  6. 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>
     
    Fredrik Lundh, Sep 21, 2008
    #6
  7. dmitrey

    Fuzzyman Guest

    On Sep 21, 4:04 pm, Fredrik Lundh <> 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
    >
    >    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/threadPrimitiveDeprecati...
    >
    > (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.

    Michael
    http://www.ironpythoninaction.com/
     
    Fuzzyman, Sep 21, 2008
    #7
  8. On 2008-09-21, Fredrik Lundh <> 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
    >
    > 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
     
    Antoon Pardon, Sep 22, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. chintan jajal via .NET 247

    Delegate Endinvoke Kill thread

    chintan jajal via .NET 247, May 24, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    6,993
    Richard Grimes [MVP]
    Jun 6, 2005
  2. Rasmus B. Nielsen

    thread kill ?

    Rasmus B. Nielsen, Aug 30, 2003, in forum: Java
    Replies:
    0
    Views:
    493
    Rasmus B. Nielsen
    Aug 30, 2003
  3. Jerry Sievers

    thread, threading; how to kill a thread?

    Jerry Sievers, Nov 17, 2004, in forum: Python
    Replies:
    12
    Views:
    1,186
    Mustafa Demirhan
    Nov 19, 2004
  4. ssylee
    Replies:
    2
    Views:
    749
    James Kanze
    Jan 28, 2008
  5. Charles Oliver Nutter
    Replies:
    43
    Views:
    665
    Roger Pack
    Mar 25, 2008
Loading...

Share This Page