We have a way to raise an exception in a thread asynchronously, *but* we don't have a way to interrupt either system calls or blocked lock acquisitions. I suppose that system calls can be made interruptable with suitable tweaking of various signal-related settings (at least on Unix -- and I expect Windows has an equivalent). But I don't know if mutex acquisitions are interruptable.
--Guido On Mon, Apr 7, 2008 at 10:43 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Mon, Apr 7, 2008 at 7:40 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > > > Maybe it should be a forked subprocess then, if it doesn't touch > > > anything shared? > > > > It might be taking and returning large data structures > > that it would be tedious to transfer between processes. > > Pickling them might not be straightforward if they > > contain references to objects that you don't want to > > transfer, but you want to maintain the references. > > > > > > > Huh? We do that all the time. We won't let you control when memory is > > > deallocated. > > > > I hardly think that being able to kill threads is > > anywhere near as dangerous as being able to scribble > > all over memory. And I *can* actually do that if I > > really want, using ctypes. :-) > > I see three levels of thread interruption. First, you might want to > poke a thread just to wake up a single system call, but the thread > might get back to work afterwards. This resembles Java's > Thread.interrupt. Second, you might want to cancel the thread, but > only in ways that let the user clean up afterward. This is vaguely > like pthread_cancel, or like Thread.interrupt with no way to clear the > interrupted status. Third, you might want to really abort the thread, > like Java's Thread.stop. > > There are uses for all three levels, but for a first implementation, I > think we should pick just one. Because aborting is unsafe in most > situations, it's out. And I vaguely remember Josh Block saying that if > he had to do Java over again, he'd make it impossible to clear a > Thread's interrupted status, turning it into cancellation, but I need > to check with him to make sure I got that right. > > I'm not opposed in theory to providing the really violent option in, > say, the version after we provide plain cooperative cancellation, but: > 1) Any given library can simulate it by calling > threading.cancellation_point() (or whatever its name turns out to be) > occasionally within its inner loop, and > 2) Judging from other systems with violent interruptions like posix > signals and Haskell asynchronous exceptions, we'll need a way of > blocking aborts in a scope, and unblocking them in a sub-scope. > > -- > Namasté, > Jeffrey Yasskin > > > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
