[Python-3000] python-safethread project status

Marcin ‘Qrczak’ Kowalczyk qrczak at knm.org.pl
Tue Mar 18 23:52:54 CET 2008


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.

> 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.

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).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/



More information about the Python-3000 mailing list