[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?

[Guido van Rossum]

On Fri, Mar 30, 2012 at 6:24 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>> There seem to be a few competing features for clocks that people want:
>>
>>  - monotonic - never going backward at all
>>  - high resolution
>
> These features look to be exclusive on Windows. On other platforms, it
> looks like monotonic clocks are always the most accurate clocks. So I
> don't think that we need to be able to combine these two "flags".
>
>>  - no steps
>
> You mean "not adjusted by NTP"? Except CLOCK_MONOTONIC on Linux, no
> monotonic clock is adjusted by NTP. On Linux, there is
> CLOCK_MONOTONIC_RAW, but it is only available on recent Linux kernel
> (2.6.28).
>
> Do you think that it is important to be able to refuse a monotonic
> clock adjusted by NTP? What would be the use case of such truly steady
> clock?

That depends on what NTP can do to the clock. If NTP makes the clock
tick *slightly* faster or slower in order to gradually adjust the wall
clock, that's fine. If NTP can make it jump wildly forward or even
backward, it's no better than time.time(), and we know why (for some
purposes) we don't want that.

> --
>
> The PEP 418 tries to expose various monotonic clocks in Python with a
> simple API. If we fail to agree how to expose these clocks, e.g.
> because there are major differences between these clocks, another
> solution is to only expose low-level function. This is already what we
> do with the os module, and there is the shutil module (and others) for
> a higher level API. I already added new "low-level" functions to the
> time module: time.clock_gettime() and time.clock_getres().
>
>> Of course you can provide some convenient-with-fallback function that
>> will let people do this in one hit without the need for "T", but it
>> should not be the base facility offered. The base should let people
>> request their feature set and inspect what is supplied.
>
> The purpose of such function is to fix programs written with Python <
> 3.3 and using time.time() whereas a monotonic would be the right clock
> (e.g. implement a timeout).
>
> Another concern is to write portable code. Python should help
> developers to write portable code, and time.monotonic(fallback=False)
> is not always available (and may fail).

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