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
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_______________________________________________
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
