On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner > <victor.stin...@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.
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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com