<html><body>On 12:06 am, greg.ewing@canterbury.ac.nz wrote:<br />>glyph@divmod.com wrote:<br />>>Can you suggest any use-cases for thread termination which will *not* <br />>>result in a completely broken and unpredictable heap after the thread has <br />>>died?<br />><br />>Suppose you have a GUI and you want to launch a<br />>long-running computation without blocking the<br />>user interface. You don't know how long it will<br />>take, so you want the user to be able to cancel<br />>it if he gets bored.<br /><br />That's a perfectly reasonable use-case which doesn't require this feature at all ;).<br /><br />>Interaction with the rest of the program is<br />>extremely limited -- some data is passed in,<br />>it churns away, and some data is returned. It<br />>doesn't matter what happens to its internal<br />>state if it gets interrupted, as it's all going<br />>to be thrown away.<br /><br />If that's true, then the state-sharing features of threads aren't required, which is the right way to design concurrent software anyway.<br /><br />>In that situation, it doesn't seem unreasonable<br />>to me to want to be able to just kill the thread.<br />>I don't see how it could do any more harm than<br />>using KeyboardInterrupt to kill a program,<br />>because that's all it is -- a subprogram running<br />>inside your main program.<br /><br />The key distinction between threads and processes is the sharing of internal program state.<br /><br />>How would you handle this situation?<br /><br />Spawn a process, deliver the result via an event.<br /><br />If you're allergic to event-driven programming, then you can spawn a process *in* a thread, and block in the thread on reading from the process's output, then kill the *process* and have that terminate the output, which terminates the read().  This is a lot like having a queue that you can put a "stop" object into, except the "file" interface provided by OSes is kind of crude.  Still no need to kill the thread.<br /><br />At the end of the day though, you're writing a GUI in this use-case and so you typically *must* be cognizant of event-driven issues anyway.  Many GUIs (even in the thread-happy world of Windows) aren't thread-safe except for a few specific data-exchange methods, which behave more or less like a queue.<br /><br />One of the 35 different existing ways in which one can spawn a process from Python, I hope, will be sufficient for this case :).<br /></body></html>