[Python-bugs-list] [Bug #121115] Kill threads from main thread

[noreply@sourceforge.net]

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

Date: 2000-Nov-02 12:04
By: gvanrossum

Comment:
As I said, signals are a Unix-only solution.

And blocked I/O is a common reason to *want* to kill a thread -- e.g. the common problem of webservers that simply never reply.
-------------------------------------------------------

Date: 2000-Nov-03 05:01
By: holtwick

Comment:
I think then it would be the best to send the asynchronous exceptions even if they don't work for blocking I/O operations. The need of killing threads from outside is obvious I think. And there will be for sure some scenarios where the killing doesn't work properly, but to avoid these situations should be a task for the programmer of the code. There are always situations where the design of a programming language will not save the programmer of writing stupid code, e.g. while 1: pass

If there is no way of implementing the killing how should one write an multithreaded long running programm that keeps itself clean for several days or months or years. The advantage of threads are the shared informations and forking is often more difficult to use.

How does Java solve these problems?
-------------------------------------------------------

Date: 2000-Nov-03 05:18
By: gvanrossum

Comment:
The common solution for things like this is to have a simple app-specific protocol involving. The thread watches a specific variable that means "please exit"; when there's a need to kill the thread this variable is set. The thread just has to be careful to check this variable in each unbounded loop. This requires a bit of discipline; but (as you say) there are too many things a programmer can do to break the program to try and prevent them all.
-------------------------------------------------------

Date: 2000-Nov-13 12:21
By: gvanrossum

Comment:
I've added this feature request to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=121115&group_id=5470