[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor report at bugs.python.org
Tue Oct 24 20:13:03 EDT 2017


STINNER Victor <victor.stinner at gmail.com> added the comment:

I merged my PR. Thanks Antoine Pitrou for the review!

This change only impacts the io.BufferedWriter and io.BufferedReader during Python finalization. It has no effect on theading.Lock.acquire(). It might impact faulthandler.dump_traceback_later(), but in practice, it shouldn't change anything since the internal faulthandler watchdog thread blocks all signals.

If I understand correctly, if the system clock is stepped back by 1 hour during Python finalization, after PyThread_acquire_lock_timed() computed the deadline, but before sem_timedwait() completed, _enter_buffered_busy() can be blocked during 1 hour.

Moving the system clock backward by 1 hour occurs once a year on the DST change. But the race condition is unlikely since the size of the time window is only 1 second. The DST change should occur at Python shutdown when an io.BufferedReader or io.BufferedWriter is used.

Since the race condition seems very unlikely and was never reported by another user, I propose to not backward this change. Moreover, I'm not confident to modify locks in a stable release :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________


More information about the Python-bugs-list mailing list