[Python-3000] python-safethread project status

[Guido van Rossum]

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 <jyasskin at gmail.com> wrote:
> 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
>
>
> _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at 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/)