[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