[Python-Dev] PEP 418: Add monotonic clock

[Guido van Rossum]

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



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