[Patches] [ python-Patches-452266 ] thread.kill_thread

noreply@sourceforge.net noreply@sourceforge.net
Tue, 16 Oct 2001 13:33:10 -0700


Patches item #452266, was opened at 2001-08-17 17:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: Later
Priority: 3
Submitted By: Jason Petrone (jpetrone)
Assigned to: Guido van Rossum (gvanrossum)
Summary: thread.kill_thread 

Initial Comment:
Function to unsafely kill a thread.  Implementations
are included for posix and nt.  If what I have looks
reasonable I will add other platforms + docs.

I've read Guido's usenet posts on this and 
understand the reasons against it, but I still think
it might be worth having.  Thread implementations 
like the ones in Java and win32 allow it with the
caveat that it could result in deadlock, 
corrupted data,  unclaimed resources, bodily harm, 
etc.  

Note that it also changes start_new_thread to return
the id for the new thread.


----------------------------------------------------------------------

>Comment By: Jason Petrone (jpetrone)
Date: 2001-10-16 13:33

Message:
Logged In: YES 
user_id=71210

I agree, throwing an exception is the only Right Way to do 
it.  Throwing it in Python code isn't really that useful,
its when a thread is IO blocked that it is really important.

I know how to do this with pthreads, but I don't know any
way to do it under windows.
The vast majority of the patch was to return the thread id 
from start_new_thread, so if that goes in I didn't really
waste any time on this.

Besides, I finally broke down and converted the socket code 
that inspired me to write this to non-blocking IO anyway.
Its ugly, but at least its safe.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-16 13:18

Message:
Logged In: YES 
user_id=6380

I'm tempted to just close this now, but I'll leave it open
to see if others have any comments. Basically, the only
thread kill that I fell comfortable with would be one that
raises an exception. This is easy if the thread is executing
Python bytecodes: just check a global flag every once in a
while. But the interesting part is when the thread is
blocked in something like a socket recv() call, and there
the only way to kill it on Unix is to send a signal to the
thread -- and on Windows I don't know how to do it. In
addition, I've just applied a patch that turns off signals
in threads other than the main thread, because in general
Python doesn't like signals being delivered to other
threads.

I'm sorry, Jason -- you did a decent amount of research on
this one, but still more is required...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 10:52

Message:
Logged In: YES 
user_id=21627

One note on killing threads: Part of working "safely" 
would be that any reference to objects that the thread 
currently holds is released when the thread is killed.

That essentially requires that all C stack frames perform 
the appropriate Py_DECREFs, which is not feasible through 
the thread kill mechanisms of the thread libraries 
(AFAIK). Instead, a Python exception is about the only 
approach that has a chance of working "safely".


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-22 01:21

Message:
Logged In: YES 
user_id=6380

Sending SIGINT may be easy, but that only covers the Unix
side. Also, catching it requires more work, interfering with
the existing signal handling, so this becomes A Project.
(So, yes, the hard part is getting Python to process signals
out of the main thread.)

Thanks for the new patch! This is a step in the right
direction. It came too late to be reviewed for 2.2a2, but
I'll try to get it into 2.2a3.

----------------------------------------------------------------------

Comment By: Jason Petrone (jpetrone)
Date: 2001-08-20 21:21

Message:
Logged In: YES 
user_id=71210

Sending SIGINT to a thread is pretty easy. Is the hard 
part of killing a thread with signals getting python to
process signals outside of the main thread?  

At any rate, I'm attaching a new patch that returns the 
thread id from start_new_thread, without any of the 
kill_thread() stuff.  It includes a change to libthread.tex.

For platforms I don't really know I just had them return -1
on failure and 0 on success so they at least run.

o Solaris, pthreads, pth - returns thread id, tested
o NT - returns thread id, (should work, haven't tested
after    removing kill)
o SGI, BeOS - returns thread id, untested
o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 
   0 on success


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 06:01

Message:
Logged In: YES 
user_id=6380

Thanks to Tim for jogging my memory.

I think an interruption facility should be a way to send an
exception to a thread, similar to KeyboardInterrupt -- the
thread can then decide what to do (and since exceptions can
happen anyway, the safety guarantee is not violated -- if
the application doesn't release locks on exceptions, it is
already unsafe).

One problem is that it's probably most important to be able
to stop a thread while it's blocked for I/O (a socket
connect() or recv() from a non-responding host is a typical
example). Unfortunately, the only way to do that on Unix is
to send a real signal to the thread. On Windows, I have no
idea.

Note that part of this patch would still be useful:
start_new_thread() should return a thread-id.

----------------------------------------------------------------------

Comment By: Jason Petrone (jpetrone)
Date: 2001-08-19 20:21

Message:
Logged In: YES 
user_id=71210

While I would very much like to have full interruption
functionality, I'm not sure how easily it could be done
on all platforms.  At the least it would be nice to have
SOME sort of thread signalling.  

What guarantees about safety should python make?  I've
considered trying to add cleanup handlers to release 
interpreter locks and such, but didn't feel like putting
that much effort into a patch that would likely be
rejected anyway.  I will look into adding cleanup routines if we can establish some requirements.  I think I 
can do it in pthreads pretty easily.  Dunno how easy the
rest will be.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:24

Message:
Logged In: YES 
user_id=31435

I've never called TerminateThread() on Win32, and given the 
dire wngs about it in the MS docs, never will.  IMO Python 
shouldn't be in this business unless it can guarantee to do 
it safely.  But it can't, so -1 from me.

Java did get out of this business:

<http://java.sun.com/products/jdk/1.2/docs/guide/misc/thread
PrimitiveDeprecation.html>

What Java has that Python lacks (follow the link) is a way 
to "interrupt" a thread, and there's nothing that was 
possible with thread.stop() that isn't possible by building 
on interruption (although the places where people really 
want this are places where thread.stop() never worked 
anyway -- Java never had a gimmick as Draconian as Win32's 
TerminateThread() -- Java's thread.stop() was "stop if you 
can, but there are many reasons you may not be able to").

I'd be +1 on a thread interruption facility for Python, 
which amounts to a way to raise an exception in a different 
thread.  But like Java's facility, it couldn't always 
guarantee the target thread would respond.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 23:27

Message:
Logged In: YES 
user_id=6380

Assigned to Tim for review of the Windows code.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 23:01

Message:
Logged In: YES 
user_id=6380

I'm +0 with this, so it can go in if people really want it.
(Though isn't this deprecated in Java?) The patch looks very
thorough. Some concerns:

- Patches for Doc/lib/libthread.tex (don't have to be
perfect LaTeX, but must document new functionality).

- For other OS thread implementations (e.g. pth, solaris,
beos, os2) the thread ID returned by the thread module is
always zero.

- Some pthread implementations seem to have an issue that
the thread-id as we calculate it is not necessarily unique,
due to the opaqueness of the pthread_t structure.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470