New submission from STINNER Victor: Currently, socket methods (ex: accept, recv, recvfrom, recvmsg, send, sendto, sendmsg), threading.Lock.acquire() and threading.RLock.acquire() use the system clock to compute their timeout. It's fine for the first call. But if the call is interrupted and the timeout need to be recomputed, it can wait too short or too long. Timeouts must use a monotonic clock, not the system clock. See the PEP 418 for more information.
Python modules were already patched to use the time.monotonic() function implemented in Python 3.3. Attached patch fixes also functions which still use the system clock to compute timeouts. A major change of the patch is that a monotonic clock is now require to use Python 3.5. Last time I checked, there was only one OS without monotonic clock: GNU Hurd. Hurd maintainers can patch Python 3.5 to fallback on the system clock until Hurd provides a monotonic clock. Another important change is that Python now depends on the librt on Solaris and on Linux with glibc older than 2.17 (clock_gettime is now available directly in the libc since glibc 2.17). ---------- files: pymonotonic.patch keywords: patch messages: 223715 nosy: haypo priority: normal severity: normal status: open title: Use a monotonic clock to compute timeouts type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36041/pymonotonic.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22043> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
