> (Btw. whatever we do, it won't interrupt blocking system calls, but I
> think that's fine. sys.interrupt() won't interrupt these either.)
In particular, this means that a thread blocked waiting for a lock
won't be stopped until the lock is released by the thread that held
the lock. If there's a deadlock, this may be never. So the mechanism
won't help you to kill deadlocked threads. (This can be alleviated by
using aquire() with a timeout everywhere; but the basic locks
currently don't have that feature, they only have a non-blocking
option. And of course code using timeouts is more complicated to
write, and harder to read.)
There's also a race condition in the language design that would need
to be fixed before I'd like to have this feature. As you know, the
proper idiom for using locks is:
lock.acquire()
try:
...critical section code...
finally:
lock.release()
It's important that the acquire() call is outside the try block,
because otherwise the release() call could be reached without the
acquire() call having returned. But now if an asynchronous exception
arrives *after* acquire() returns but *before* the try block is
entered, the lock is never released!
I've seen a proposal (I think it was in a paper presented at the
second Little Languages conference at MIT, earlier this year) of a
syntactic extension that could be used:
initially:
lock.acquire()
try:
...critical section code...
finally:
lock.release()
(this would block asynchronous signals during the initially: block)
but that's a pretty heavy-handed solution.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4