[Python-Dev] PEP 418: Add monotonic clock

[Scott Dial]

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? 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 CLOCK_MONOTONIC
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