On 12:06 am, 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. That's a perfectly reasonable use-case which doesn't require this feature at all ;). >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. If that's true, then the state-sharing features of threads aren't required, which is the right way to design concurrent software anyway. >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. The key distinction between threads and processes is the sharing of internal program state. >How would you handle this situation? Spawn a process, deliver the result via an event. 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. 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. One of the 35 different existing ways in which one can spawn a process from Python, I hope, will be sufficient for this case :). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070316/131a3f48/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4