[Python-Dev] PEP 418: Add monotonic clock
Victor Stinner
victor.stinner at gmail.com
Thu Mar 29 01:27:44 CEST 2012
> Where in the stdlib do we actually calculate timeouts instead of using
> the timeouts built into the OS (e.g. select())?
At least in threading and queue modules. The common use case is to
retry a function with a timeout if the syscall was interrupted by a
signal (EINTR error). The socket module and _threading.Lock.acquire()
implement such retry loop using the system clock. They should use a
monotonic clock instead.
> I think it would be nice if we could somehow use the *same* clock as
> the OS uses to implement timeouts.
On Linux, nanosleep() uses CLOCK_MONOTONIC whereas POSIX suggests
CLOCK_REALTIME. Some functions allow to choose the clock, like pthread
locks or clock_nanosleep().
> I'd be happier if the fallback function didn't try to guarantee things
> the underlying clock can't guarantee. I.e. I like the idea of having a
> function that uses some accurate OS clock if one exists but falls back
> to time.time() if not; I don't like the idea of that new function
> trying to interpret the value of time.time() in any way.
We may workaround some OS known bugs like:
http://support.microsoft.com/?id=274323
The link contains an example how to workaround the bug. The idea of
the workaround is to use two different monotonic clocks to detect
leaps, with one trusted clock (GetTickCount) and one untrusted clock
having an higher resolution (QueryPerformanceCounter).
I don't think that the same algorithm is applicable on other OSes
because other OSes usually only provide one monotonic clock, sometimes
though different API.
Victor
More information about the Python-Dev
mailing list