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

Guido van Rossum guido at python.org
Wed Mar 28 23:50:41 CEST 2012

On Wed, Mar 28, 2012 at 2:36 PM, Scott Dial <scott+python-dev at scottdial.com> wrote:

On 3/28/2012 10:29 AM, Guido van Rossum wrote:

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

Completely unintuitive and unnecessary. With the GIL taking care of synchronisation issues, we can easily coerce time.time() into being a monotonic clock by the simple expedient of saving the last returned value:

That's a pretty obvious trick. But why don't the kernels do this if monotonicity is so important? I'm sure there are also downsides, e.g. if the clock is accidentally set forward by an hour and then back again, you wouldn't have a useful clock for an hour. And the cache is not shared between processes so different processes wouldn't see the same clock value (I presume that most of these clocks have state in the kernel that isn't bound to any particular process -- AFAIK only clock() does that, and only on Unixy systems). What makes you think that isn't already true?

What does "that" refer to in this sentence?

I don't know what platforms that CPython compiles for that won't have one of the aforementioned functions available that provide a real monotonic clock. Surely, any platform that doesn't didn't recognize the need for it, or they would just provide a monotonic clock. That is to say, if you are a POSIX compliant system, then there is no reason to break gettimeofday() and friends when you can just implement CLOCKMONOTONIC proper (even if it's just a trick like Nick's).

I think the PEP should enumerate what platforms that CPython supports that will not benefit from a real monotonic clock. I think the number of platforms will be such a minority that the emulation makes sense. Practicality beats purity, and all. -- Scott Dial scott at scottdial.com

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

More information about the Python-Dev mailing list