[issue41710] Timeout is affected by jumps in system time
New submission from Jonas Norling : The timeout for threading.Lock, threading.Condition, etc, is not using a monotonic clock — it is affected if the system time (realtime clock) is set. The attached program can be used to show the problem. It is expected to print "Took 2.000 s" repeatedly, but if run with permissions to set the system time, it prints: $ sudo ./time_test.py Took 2.400 s Took 1.657 s Took 2.044 s Took 2.401 s ... (the 1.6 s time can be explained by NTP correcting the clock) There are already a number of closed bugs for this and related issues: bpo 23428, bpo 31267, bpo 35747. This happens in Python 3.7.7 (ARM32, Yocto Warrior), Python 3.8.2 (AMD64, Ubuntu Linux 20.04) and Python v3.9.0rc1 (AMD64, Ubuntu Linux 20.04). -- components: Interpreter Core files: time_test.py messages: 376338 nosy: wocket priority: normal severity: normal status: open title: Timeout is affected by jumps in system time type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49440/time_test.py ___ Python tracker <https://bugs.python.org/issue41710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41710] Timeout is affected by jumps in system time
Jonas Norling added the comment: sys.thread_info = sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.31') on my system. Looking at the source I think the semaphore implementation will be used on all modern Linux systems. In my tests it works as expected on a Macintosh (3.8.5 with lock='mutex+cond') and also if I force a Linux build to use the mutex+cond implementation by defining HAVE_BROKEN_POSIX_SEMAPHORES. Doesn't look like those glibc and Linux bug reports will get any attention anytime soon. I will find a workaround instead :-/ -- ___ Python tracker <https://bugs.python.org/issue41710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order
Jonas Norling added the comment: @bar.harel: I didn't find a PR, so I'd like to encourage you to submit one :-) I stumbled onto this bug when the scheduler would cancel the wrong event for me (Python 3.7, 3.8). Raymond's suggestion 1 sounds reasonable; it would be very unlikely to break code that doesn't depend on internals in sched, and it simplifies the implementation a bit. -- nosy: +wocket ___ Python tracker <https://bugs.python.org/issue19270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
