threads killing other threads 
Author Message
 threads killing other threads

I've occasionally wanted thread objects to have an exit() method, so that
one thread could interrrupt and kill another.  This doesn't seem to be
available, perhaps because POSIX threads don't support it.

Is that correct?

Is there some reason why threads killing threads would be undesirable or
hard to implement?

Greg



Tue, 27 Jul 2004 02:19:30 GMT  
 threads killing other threads

Quote:

> I've occasionally wanted thread objects to have an exit() method, so that
> one thread could interrrupt and kill another.  This doesn't seem to be
> available, perhaps because POSIX threads don't support it.

> Is that correct?

> Is there some reason why threads killing threads would be undesirable or
> hard to implement?

I don't know the reasoning behind threads being unkillable (from outside),
but I do know the (apparently standard) way to accomplish what you want.

Create a global threading.Event object, named something descriptive like
Quit, and have every thread peek at it occasionally.  If the Quit event is
set, then the thread aborts.  If you need to be able to kill specific threads
individually, then you have a separate event object for each thread.

Of course, this *does* rely on the threads being well-behaved, and not
getting stuck in an infinite loop elsewhere, and so on....  but then, that's
pretty much a requirement anyhow.

Jeff Shannon
Technician/Programmer
Credit International



Tue, 27 Jul 2004 04:17:26 GMT  
 threads killing other threads
|
| > I've occasionally wanted thread objects to have an exit() method, so that
| > one thread could interrrupt and kill another.  This doesn't seem to be
| > available, perhaps because POSIX threads don't support it.
| >
| > Is that correct?
| >
| > Is there some reason why threads killing threads would be undesirable or
| > hard to implement?
|
| I don't know the reasoning behind threads being unkillable (from outside),

Here's an analogy :

If someone is sitting on the toilet, then you come and kill him, how
is he supposed to flush?

Processes can be killed by other processes since their resources are
separate and the kernel can "flush" for the now-dead process.  With
threads, there is one process and all resources are shared.  No one is
left around to "flush".

-D

--

He who spares the rod hates his son,
but he who loves him is careful to discipline him.
        Proverbs 13:24



Tue, 27 Jul 2004 05:01:27 GMT  
 threads killing other threads

Quote:

> I've occasionally wanted thread objects to have an exit() method, so that
> one thread could interrrupt and kill another.  This doesn't seem to be
> available, perhaps because POSIX threads don't support it.

> Is that correct?

> Is there some reason why threads killing threads would be undesirable or
> hard to implement?

What you really want is a way to let threads raise asynchronous
exceptions in other threads.  There's some discussion of this in

http://sf.net/tracker/?func=detail&aid=502236&group_id=5470&atid=105470



Tue, 27 Jul 2004 09:16:05 GMT  
 threads killing other threads

    Jeff> Create a global threading.Event object, named something
    Jeff> descriptive like Quit, and have every thread peek at it
    Jeff> occasionally.  If the Quit event is set, then the thread aborts.
    Jeff> If you need to be able to kill specific threads individually, then
    Jeff> you have a separate event object for each thread.

    Jeff> Of course, this *does* rely on the threads being well-behaved, and
    Jeff> not getting stuck in an infinite loop elsewhere, and so on....
    Jeff> but then, that's pretty much a requirement anyhow.

This note from the threading module docs suggests to me a different way to
do things:

    A thread can be flagged as a ``daemon thread''.  The significance of
    this flag is that the entire python program exits when only daemon
    threads are left.

If all your worker threads are daemon threads, when your main thread exits,
the program should exit as well.  I haven't tried this, but may well try it
shortly.  I do have trouble getting a multi-threaded server to exit.

--



Tue, 27 Jul 2004 12:23:51 GMT  
 threads killing other threads

    Greg> I've occasionally wanted thread objects to have an exit()
    Greg> method, so that one thread could interrrupt and kill
    Greg> another.  This doesn't seem to be available, perhaps because
    Greg> POSIX threads don't support it.

    Greg> Is that correct?

    Greg> Is there some reason why threads killing threads would be
    Greg> undesirable or hard to implement?

Posix defines a pthread_cancel that lets one thread cancel another
thread. From the man page:

       Cancellation is the mechanism by which a thread can termi-
       nate  the  execution  of another thread. More precisely, a
       thread can send a cancellation request to another  thread.
       Depending  on  its  settings,  the  target thread can then
       either ignore the request, honor it immediately, or  defer
       it till it reaches a cancellation point.

I'm sure there's a good reason for Python not implementing
this. Anyone know what it is?



Tue, 27 Jul 2004 20:35:00 GMT  
 threads killing other threads


Quote:

>I'm sure there's a good reason for Python not implementing this. Anyone
>know what it is?

Yes.  It doesn't work.  

Oh, sure, there's a long technical explanation of how arbitrarily
killing threads leaves processes in various kinds of weird states, but
it all boils down to, "It doesn't work."  That goes double for any kind
of cross-platform facility.  Note that Java has pretty much abandoned any
pretence that it can provide this capability.
--

Hugs and backrubs -- I break Rule 6                 http://www.*-*-*.com/
Androgynous poly {*filter*} vanilla {*filter*} het Pythonista

"We should forget about small efficiencies, about 97% of the time.
Premature optimization is the root of all evil."  --Knuth



Tue, 27 Jul 2004 23:45:04 GMT  
 threads killing other threads



    >>  I'm sure there's a good reason for Python not implementing
    >> this. Anyone know what it is?

    Aahz> Yes.  It doesn't work.

    Aahz> Oh, sure, there's a long technical explanation of how
    Aahz> arbitrarily killing threads leaves processes in various
    Aahz> kinds of weird states, but it all boils down to, "It doesn't
    Aahz> work."  That goes double for any kind of cross-platform
    Aahz> facility.  Note that Java has pretty much abandoned any
    Aahz> pretence that it can provide this capability.  -- --- Aahz

But doesn't pthread_testcancel allow cooperative threads to be
canceled? This is the portable equivalent to the thread signaling
scheme described earlier. It also gives the canceled thread a chance
to clean itself up before exiting.

Not ideal, but better than nothing.



Wed, 28 Jul 2004 05:17:07 GMT  
 threads killing other threads
[Les Smithson]

Quote:
> But doesn't pthread_testcancel allow cooperative threads to be
> canceled?

Yes.

Quote:
> This is the portable equivalent to the thread signaling scheme
> described earlier.

It's only portable among platforms with pthreads implementations recent
enough to include it.  The thread facilities Python exposes are much more
portable than that.

Quote:
> It also gives the canceled thread a chance to clean itself up before
> exiting.

Yes, provided you expose more and more of pthread-specific functionality to
get at all this stuff.

Quote:
> Not ideal, but better than nothing.

I'm afraid the truly portable part of it remains nothing.  Someone may care
to write a pthreads-specific extension to Python's threading facilities,
though.  Note that what people actually ask for is a way to *force* another
thread to terminate (even if it's, e.g., stuck in a blocking I/O call), so
the audience for this kind of gimmick gets slashed repeatedly each time
reality objects <wink>.

don't-use-threads-when-you-want-processes-ly y'rs  - tim



Wed, 28 Jul 2004 12:31:55 GMT  
 threads killing other threads


Quote:



>>>  I'm sure there's a good reason for Python not implementing
>>> this. Anyone know what it is?

>> Yes.  It doesn't work.

>> Oh, sure, there's a long technical explanation of how arbitrarily
>> killing threads leaves processes in various kinds of weird states,
>> but it all boils down to, "It doesn't work."  That goes double for
>> any kind of cross-platform facility.  Note that Java has pretty much
>> abandoned any pretence that it can provide this capability.

>But doesn't pthread_testcancel allow cooperative threads to be
>canceled? This is the portable equivalent to the thread signaling
>scheme described earlier. It also gives the canceled thread a chance to
>clean itself up before exiting.

>Not ideal, but better than nothing.

After looking this up, I see two basic problems with this:

* Doesn't work with extensions unless the extension writer cooperates.

* Don't see any direct equivalent in Win32.  Solaris native threads
don't support this; I don't know off-hand whether Python uses pthreads
on Solaris.
--

Hugs and backrubs -- I break Rule 6                 http://www.*-*-*.com/
Androgynous poly {*filter*} vanilla {*filter*} het Pythonista

"Argue for your limitations, and sure enough they're yours."  --Richard Bach



Tue, 24 Aug 2004 10:24:54 GMT  
 threads killing other threads
If outright killing is disallowed, I'd still like to see the ability
for one thread to cause an exception to be thrown in another.
Currently you can do this to the main thread (on UNIX) by using
process signals.
Quote:

> Here's an analogy :
> If someone is sitting on the toilet, then you come and kill him, how
> is he supposed to flush?
> Processes can be killed by other processes since their resources are
> separate and the kernel can "flush" for the now-dead process.  With
> threads, there is one process and all resources are shared.  No one is
> left around to "flush".



Tue, 24 Aug 2004 21:48:16 GMT  
 threads killing other threads

Quote:

> If outright killing is disallowed, I'd still like to see the ability
> for one thread to cause an exception to be thrown in another.
> Currently you can do this to the main thread (on UNIX) by using
> process signals.

You could always "roll it yourself" by having a threading.Event object
shared between the threads - one thread sets the event to tell the
other to raise an exception/exit/stop processing/whatever.

Or here's a mad idea...  You could have a Queue.Queue object shared
between the threads, and the first thread could create an Exception
object of whatever class it wanted raised (ie not raise it itself,
just create the instance) , pass _that_ through the queue, and have
the other thread raise it.  Why you'd want to do this I'm not sure,
but it _would_ work, wouldn't it?  Er, I think.

Of course, both of these ideas mean the second thread has to have some
mechanism for checking the Event or Queue, which may be more work than
it's worth.

Just thinking with my keyboard...  :-)

-Andy

--
Andy Gimblett - Programmer - Frontier Internet Services Limited
Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
Statements made are at all times subject to Frontier's Terms and
Conditions of Business, which are available upon request.



Tue, 24 Aug 2004 22:33:46 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Thread#kill doesn't kill processes inside a thread

2. How to kill a thread from another thread ?

3. threading: how to kill a (possibly blocked) thread?

4. Threads creating threads creating threads...

5. thread, threading, mutex modules and non-threading interpreters

6. How can you kill a thread ???

7. Vispro Rexx can't kill a rxftp thread

8. Is there a REXX Kill Thread Function?

9. killing a thread and its child

10. Kill this thread.

11. Killing a running thread

12. Sockets, threads, and killing servers

 

 
Powered by phpBB® Forum Software