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/archive%40mail-archive.com