[Patches] [ python-Patches-452266 ] thread.kill_thread
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 19 Aug 2001 20:21:13 -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: None
Priority: 5
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-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