[Python-3000] python-safethread project status

Adam Olsen rhamph at gmail.com
Wed Mar 19 00:07:34 CET 2008


On Tue, Mar 18, 2008 at 4:52 PM, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:
> Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
>
>
>  > Search for info on java's deprecated Thread.stop() if you're not
>  > already familiar with the problems it has.
>
>  The problem with Java's Thread.stop() is that it is not possible to
>  block it in a given region, and that it is not possible to install
>  a different handler than throwing an exception. The first issue is
>  critical. If interrupts can't be blocked, it is impossible to declare
>  that a given operation is to be performed in whole or not at all, and
>  this is indeed unsafe.
>
>  If interrupts can be blocked, things are quite different, and I believe
>  that obtaining safe code is practical enough to make defaulting to
>  asynchronous interrupts a viable option.

I disagree.  In theory you could block things extensively enough that
you'd be okay, but eventually you become equivalent to deferred - only
with a great deal more boilerplate.  The maintenance and testing
issues make it impractical.

Handlers are irrelevant.  Use those for signal handling, not thread
cancellation.


>  > You mean the *entire* time a mutex is held?  That wouldn't work for
>  > monitors, as they expect to hold their lock for extended periods of
>  > time.
>
>  Aren't you including the time when a thread issues Monitor.wait()?
>  The mutex is unlocked there.
>
>  The coding style I am familiar with advises to not block while having
>  a lock. Also note that pthread_mutex_lock is not a cancellation point,
>  even though it can suspend the current thread.

Keeping your critical sections tiny may be "good practise", but it's
not possible to do all the time.  In some cases you don't intend
another thread to modify your datastructures for a long period of
time.  In C you might skip locking altogether, but with safethread
you'll likely stick them in a monitor and never release the monitor.

Also, although conceptually related to posix cancellation points, by
aware that my implementation is totally independent.


>  In any case, in my language you can explicitly unblock interrupts
>  under a mutex, and of course waiting on a condition variable is normally
>  interruptible (the associated mutex is unlocked).


-- 
Adam Olsen, aka Rhamphoryncus


More information about the Python-3000 mailing list