The lock (at least RWLockWrite, have not tested with others) has consistent issues with poorly timed KeyboardInterrupts (and presumably other interrupting signals) that arrive during acquire, at least on Windows.
Specifically, if a keyboard interrupt is received during the write lock's acquire (did not test read lock's acquire):
- A following
release() will yield an exception "released unlocked lock", yet
- A subsequent
acquire() - from either a write or read lock - will deadlock.
Therefore the lock is left in an unrecoverable state after acquire is interrupted.
The following program reproduces the issue on Windows 10 with Python 3.11.1 and readerwriterlock 1.0.9:
from readerwriterlock import rwlock
lock = rwlock.RWLockWrite()
wlock = lock.gen_wlock()
rlock = lock.gen_rlock()
print("running wlock loop, press ctrl-c to proceed")
while True:
try:
wlock.acquire()
except KeyboardInterrupt:
print("keyboard interrupt received")
break
finally:
try:
wlock.release()
except Exception as x:
print(f"warning: {x}")
print("acquiring rlock")
rlock.acquire()
print("releasing rlock")
rlock.release()
print("finished")Pressing Ctrl-C during the loop is more likely than not to leave the lock in this indeterminate state.
The ultimate consequence, in my case anyways, is that terminating an application cleanly in response to an interrupt signal becomes tricky, as workarounds need to be put in place to handle the possibility of deadlocks as well as handle the "released unlock lock" exception.
The lock (at least
RWLockWrite, have not tested with others) has consistent issues with poorly timedKeyboardInterrupts(and presumably other interrupting signals) that arrive duringacquire, at least on Windows.Specifically, if a keyboard interrupt is received during the write lock's
acquire(did not test read lock'sacquire):release()will yield an exception "released unlocked lock", yetacquire()- from either a write or read lock - will deadlock.Therefore the lock is left in an unrecoverable state after acquire is interrupted.
The following program reproduces the issue on Windows 10 with Python 3.11.1 and readerwriterlock 1.0.9:
Pressing Ctrl-C during the loop is more likely than not to leave the lock in this indeterminate state.
The ultimate consequence, in my case anyways, is that terminating an application cleanly in response to an interrupt signal becomes tricky, as workarounds need to be put in place to handle the possibility of deadlocks as well as handle the "released unlock lock" exception.