[New-bugs-announce] [issue22043] Use a monotonic clock to compute timeouts

[STINNER Victor]

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 <report at bugs.python.org>
<http://bugs.python.org/issue22043>
_______________________________________