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

[Victor Stinner]

>> Impact: A timeout may be 42 seconds shorter than the requested
>> duration if is uses QPC. For a scheduler, a task would be scheduled at
>> the right moment.
>
> I don't understand this paragraph. And why is it always exactly a loss
> of 42 seconds?

Sorry, it's late here, I'm too tired. A jump of 42 seconds is one of
QPC known bug (it was a bug in VirtualBox and it is now fixed).

> So is it worth having two functions that are only different on
> Windows? ISTM that the average non-Windows user will have a 50% chance
> of picking the wrong timer from a portability perspective.

Can we solve this by documenting correctly time.highres() issues (it's
not really monotonic) and when you need to use time.monotonic() or
time.highres()?

Well, there is already time.clock() that uses QPC on Windows, but
time.highres() and time.clock() give different results for an idle
process on UNIX. pybench, timeit and other programs have their own
heuristic getting the most accurate clock depending on the OS and on
which clocks are available. time.highres() is a portable function for
these programs.

>> See Zooko Wilcox-O'Hearn's email:
>> http://mail.python.org/pipermail/python-dev/2012-March/118147.html
>
> He explains the basic difference between the two types of clocks, and
> that's important. He doesn't say anything about a strict requirement
> for monotonicity or steadiness. This is why I still balk at
> "monotonic" for the name -- I don't think that monotonicity is the
> most important property. But I don't know how the put the desired
> requirement in words; "steady" seems to come closer for sure.

If we provide a way to check if the monotonic clock is monotonic (or
not), I agree to drop the flag from time.monotonic(fallback=True) and
always fallback. I was never a fan of the "truly monotonic clock".

time.clock_info('monotonic')['is_monotonic'] is a good candidate to
store this information.

"time.clock_info('monotonic')['is_monotonic']" looks like a bug: why
would I check if a *monotonic* clock is *monotonic*?
time.clock_info('steady')['monotonic'] looks more natural, but I don't
remember why we should not use the term "steady".

>> Well, the PEP mentions something like that in the "One function, no
>> flag" section.
>
> But you don't seem to like it. (In general the alternatives section
> could do with reasons for rejection or at least pros and cons for each
> alternative.)

I was concerned by the fact that time.monotonic() may become
not-monotonic between two calls, but I changed my mind. I agree that
it should not occur in practice. So always fallback and add a way to
know if the monotonic clock is monotonic now sounds like the best API
to me.

Victor