This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients neologix, pitrou, vstinner
Date 2017-10-25.00:13:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508890383.94.0.213398074469.issue30768@psf.upfronthosting.co.za>
In-reply-to
Content
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 :-)
History
Date User Action Args
2017-10-25 00:13:04vstinnersetrecipients: + vstinner, pitrou, neologix
2017-10-25 00:13:03vstinnersetmessageid: <1508890383.94.0.213398074469.issue30768@psf.upfronthosting.co.za>
2017-10-25 00:13:03vstinnerlinkissue30768 messages
2017-10-25 00:13:03vstinnercreate