Message413118
> The race on := is much smaller than the original race
> and I suspect in practice will be very hard to hit.
In Windows, the acquire() method of a lock can't be interrupted. Thus, in the main thread, an exception from Ctrl+C gets raised as soon as acquire() returns. This exception definitely will interrupt the assignment. Here's a workaround:
global scope:
_WINDOWS = _sys.platform == 'win32'
in _wait_for_tstate_lock():
acquired = None
try:
if acquired := lock.acquire(block, timeout):
lock.release()
self._stop()
except:
if _WINDOWS and acquired is None:
acquired = True
if acquired:
lock.release()
self._stop()
raise
This doesn't help in POSIX if the STORE_FAST instruction that assigns `acquired` gets interrupted. This can't be distinguished from acquire() itself getting interrupted. But at least the window for this is as small as possible. |
|
Date |
User |
Action |
Args |
2022-02-12 08:46:07 | eryksun | set | recipients:
+ eryksun, pitrou, vstinner, serhiy.storchaka, Kevin Shweh, bjs, SnoopJeDi |
2022-02-12 08:46:07 | eryksun | set | messageid: <1644655567.56.0.12209884858.issue46726@roundup.psfhosted.org> |
2022-02-12 08:46:07 | eryksun | link | issue46726 messages |
2022-02-12 08:46:07 | eryksun | create | |
|