[Python-Dev] Status of thread cancellation

Giovanni Bajo rasky at develer.com
Fri Mar 16 09:55:03 CET 2007


On 16/03/2007 1.06, Greg Ewing 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.
> 
> There's no single place in the code where you
> could put in a check for cancellation. Sprinkling
> such checks all over the place would be tedious,
> or even impossible if large amounts of time are
> spent in calls to a third-party library that
> wasn't designed for such things.
> 
> Interaction with the rest of the program is
> extremely limited -- some data is passed in,
> it churns away, and some data is returned. It
> doesn't matter what happens to its internal
> state if it gets interrupted, as it's all going
> to be thrown away.
> 
> In that situation, it doesn't seem unreasonable
> to me to want to be able to just kill the thread.
> I don't see how it could do any more harm than
> using KeyboardInterrupt to kill a program,
> because that's all it is -- a subprogram running
> inside your main program.
> 
> How would you handle this situation?

It's really simple: don't use threads, use processes!

Spawn an external process which does the calculation, pass data to it through 
pipe/socket/namedpipe/xmlrpc/whatever and read data back from it when it's 
done. If you need to kill it, just kill it away, at any asynchronous time: the 
OS will clean up after it.

After many years working with these issues, I came to the personal conclusion 
of avoiding threads as much as possible. Threads are processes with shared 
memory, but in many real-world use cases I faced, there is really only a very 
little chunk of memory which is shared, and Python makes it incredibly easy to 
marshal data to a process (pickle or whatever). So in many cases there's 
really little excuses for going mad with threads.
-- 
Giovanni Bajo



More information about the Python-Dev mailing list