[Python-Dev] Status of thread cancellation

[Josiah Carlson]

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> glyph at divmod.com wrote:
> 
> > Can you suggest any use-cases for thread termination which will *not* 
> > result in a completely broken and unpredictable heap after the thread 
> > has died?
> 
> Suppose you have a GUI and you want to launch a
> long-running computation without blocking the
> user interface. You don't know how long it will
> take, so you want the user to be able to cancel
> it if he gets bored.

If the code is in Python, you can use sys.settrace to handle this. If
the code is in an extension module that a user has control over, having
a cancel_thread() function that is made available to Python, and having
your C code check the value of a single variable every few seconds could
do the same thing (even checking the value in a tight loop shouldn't
slow computations down significantly, branch prediction should be able
to make it a more or less zero-cost operation).  Yes, it can be tedious,
but at least the programmer can actually control cleanup in a reasonable
manner.

The only case that I have been able to come up with that is not covered
with these two is if you have no control over the C-level code, which
would be the case in a precompiled 3rd party extension or system call. 
In the system call case, I'm not sure there is a sane way to abort it on
all platforms, and I can just about guarantee that even if you *could*
kill a thread, doing so in 3rd party code (depending on the code) could
leave you in a questionable state (memory leaks, temporary files, broken
data structures, etc.).

It seems better to write to allow for cancellation, rather than adding a
big red STOP button to threads.

 - Josiah