Message413191
>> is there a bulletproof way to guarantee that `self._stop()` gets
>> called if the acquire_and_release() succeeds?
> I don't think it's critical.
Agreed! Anything at the Python level that cares whether the thread is still alive will call _wait_for_tstate_lock() again, and get another chance each time to notice that the tstate lock has been freed.
Instead of:
try:
if lock.acquire_and_release(block, timeout):
self._stop
except:
if not lock.locked():
self._stop()
I'd prefer:
try:
lock.acquire_and_release(block, timeout)
finally:
if not lock.locked():
self._stop()
Because, at the Python level, whether acquire_and_release() succeeded at its task depends entirely on whether the lock is free afterward. That's what we're _really_ looking for, and is so on all possible platforms. |
|
Date |
User |
Action |
Args |
2022-02-13 18:41:15 | tim.peters | set | recipients:
+ tim.peters, pitrou, vstinner, serhiy.storchaka, eryksun, Kevin Shweh, bjs, SnoopJeDi |
2022-02-13 18:41:15 | tim.peters | set | messageid: <1644777675.0.0.700563733952.issue46726@roundup.psfhosted.org> |
2022-02-13 18:41:14 | tim.peters | link | issue46726 messages |
2022-02-13 18:41:14 | tim.peters | create | |
|