[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Guido van Rossum guido at python.org
Wed Mar 28 16:42:13 CEST 2012

On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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

As I said, I think the caching idea is bad. We may have to settle for semantics that are less than perfect -- presumably if you are doing benchmarking you just have to throw away a bad result that happened to be affected by a clock anomaly, and if you are using timeouts, retries are already part of life.

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.

I would love to have only one new clock function in 3.3.

Regards, Nick.

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

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list