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).

On FreeBSD and OpenBSD, clock_gettime() is directly available in the libc.

Status of CLOCK_MONOTONIC in Hurd:
https://github.com/ArneBab/hurd-web/blob/master/open_issues/clock_gettime.mdwn

pymonotonic.patch is large and difficult to review. I prefer to split it into two parts:

• pytimespec.patch: Change pytime.h to use _PyTimeSpec structure (nanosecond resolution) instead of _PyTime_timeval structure (microsecond resolution)

• pymonotonic-2.patch: Add _PyTimeSpec_monotonic() and _PyTimeSpec_monotonic_info()

pytimespec.patch removes *private* functions which were exposed in the stable ABI:

• _PyTime_gettimeofday()
• _PyTime_gettimeofday_info()

It also removes private macros:

• _PyTime_ADD_SECONDS()
• _PyTime_INTERVAL()

In pymonotonic.patch, I reused the same name but I didn't notice that they were part of the stable ABI. In pymonotonic-2.patch, I changed names so the dynamic loader will not load a module and the compiler will complain that symbols are missing.

Replaced/renamed functions:

• _PyTime_gettimeofday() => _PyTimeSpec_get_time()
• _PyTime_gettimeofday_info() => _PyTimeSpec_get_time_info()
• _PyTime_ADD_SECONDS() => _PyTimeSpec_add_sec()
• _PyTime_INTERVAL() => _PyTimeSpec_interval_sec()

I aslo added new functions:

• _PyTimeSpec_add_us()
• _PyTimeSpec_interval_us()

On overflow, _PyTimeSpec_add_sec() and _PyTimeSpec_add_us() sets the timestamp to the maximum value instead of returning an undefined value. I prefer functions over macros because I want to return an error on overflow (even if it's not used).

_PyTimeSpec_interval_us() also returns the maximum value in case of overflow.

_PyTimeSpec_interval_sec() should maybe take a mandatory round parameter instead of always rounding up.

I added _PyTime_unit_t for _threadmodule.c because acquire_timed() has a PY_TIMEOUT_T type which can be a long long. Maybe acquire_timed() can return an error if the timeout is too large, or loop? I would prefer to avoid this custom _PyTime_unit_t type.

I should maybe add unit tests for _PyTimeSpec_add_() and _PyTimeSpec_interval_() functions, as I did for _PyLong_FromTime_t(), _PyTime_ObjectToTimeval(), etc.

Oh, pymonotonic-2.patch didn't get its "review" link because it depends on pytimespec.patch which is not merged yet.

pytimespec.patch become too large, I splitted this patch into a new issue: issue bpo-22117. If this issue is rejected, I will rewrite pymonotonic-2.patch to use the _PyTime_timeval structure.

To have an even smaller patch, I created the issue bpo-22287 just to add the dependency to the librt module in pytime.c.

New changeset 668e0bf30042 by Victor Stinner in branch 'default':
Issue bpo-22043: _PyTime_Init() now checks if the system clock works.
http://hg.python.org/cpython/rev/668e0bf30042

New changeset 76bc15c918b1 by Victor Stinner in branch 'default':
Issue bpo-22043: Simplify time.perf_counter() on Windows
http://hg.python.org/cpython/rev/76bc15c918b1

New changeset ab81b4cdc33c by Victor Stinner in branch 'default':
Issue bpo-22043: Oops, fix perf_counter() on UNIX if no monotonic clock is
http://hg.python.org/cpython/rev/ab81b4cdc33c

Ok, I prepared Python for monotonic clock, I attached an updated patch. It is now much simpler.

pymonotonic-3.patch:

• time.monotonic() is now always available

• _PyTime_Init() ensures that the operating system provides a monotonic clock and that the clock works

• Python 3.5 now requires a monotonic clock. All operating systems supported by Python 3.5 provides a monotonic clock. GNU Hurd doesn't, but it is not supported.

• drop try/except ImportError around "from time import monotonic"

• use a monotonic clock in _thread, gc and socket modules to compute elapsed time and timeouts

pymonotonic-4.patch: Updated patch (version 4) to address Antoine Pitrou's comments on Rietveld.

New changeset 330bd57685fc by Victor Stinner in branch 'default':
Issue bpo-22043: Fix _PyTime_gettimeofday() if HAVE_GETTIMEOFDAY
http://hg.python.org/cpython/rev/330bd57685fc

New changeset b12857782041 by Victor Stinner in branch 'default':
Issue bpo-22043: time.monotonic() is now always available
http://hg.python.org/cpython/rev/b12857782041

New changeset 9deef14393d5 by Victor Stinner in branch 'default':
Issue bpo-22043: Fix pymonotonic(), use tv_usec=-1 as a marker to skip
http://hg.python.org/cpython/rev/9deef14393d5

Thanks for the review Antoine. I pushed the new version pymonotonic-4.patch with a minor change: in debug mode, pymonotonic() also ensures that the clock never goes backward!

Buildbots are happy, I close the issue.