[Python-Dev] PEP 418: Add monotonic clock

[Nick Coghlan]

On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>> If we're simplifying the idea to only promising a monotonic
>> clock (i.e. will never go backwards within a given process, but may
>> produce the same value for an indefinite period, and may jump forwards
>> by arbitrarily large amounts),
>
> I don't know any monotonic clock jumping "forwards by arbitrarily
> large amounts". Linux can change CLOCK_MONOTONIC speed, but NTP
> doesn't "jump".

If I understood Glyph's explanation correctly, then if your
application is running in a VM and the VM is getting its clock data
from the underlying hypervisor, then suspending and resuming the VM
may result in forward jumping of the monotonic clocks in the guest OS.
I believe suspending and hibernating may cause similar problems for
even a non-virtualised OS that is getting its time data from a
real-time clock chip that keeps running even when the main CPU goes to
sleep. (If I *misunderstood* Glyph's explanation, then he may have
only been talking about the latter case)

Monotonicity is fairly easy to guarantee - you just remember the last
value you returned and ensure you never return a lower value than that
for the lifetime of the process. The only complication is thread
synchronisation, and the GIL (or a dedicated lock for
Jython/IronPython) can deal with that. Steadiness, on the other hand,
requires a real world time reference and is thus really the domain of
specialised hardware like atomic clocks and GPS units rather than
software that can be suspended and resumed later without changing its
internal state. There's a reason comms station operators pay
substantial chunks of money for time & frequency reference devices
[1].

This is why I now think we only need one new clock function:
time.monotonic(). It will be the system monotonic clock if one is
available, otherwise it will be our own equivalent wrapper around
time.time() that just caches the last value returned to ensure the
result never goes backwards.

With time.monotonic() guaranteed to always be available, there's no
need for a separate function that falls back to an unconditioned
time.time() result.

Regards,
Nick.

[1] For example:
http://www.symmetricom.com/products/gps-solutions/gps-time-frequency-receivers/XLi/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia