[Python-3000] python-safethread project status

[Jeffrey Yasskin]

On Mon, Apr 7, 2008 at 7:40 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> 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