[Python-Dev] Drop the new time.wallclock() function?
Matt Joiner
anacrolix at gmail.com
Wed Mar 14 17:11:56 CET 2012
I have some observations regarding this:
Victor's existing time.monotonic and time.wallclock make use of
QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
these are hardware-based counters, their monotonicity is just a
convenient property of the timer sources. Furthermore, time values can
actually vary depending on the processor the call is served on.
time.hardware()? time.monotonic_raw()?
There are bug reports on Linux that CLOCK_MONOTONIC isn't always
monotonic. This is why CLOCK_MONOTONIC_RAW was created. There's also
the issue of time leaps (forward), which also isn't a problem with the
latter form. time.monotonic(raw_only=False)?
The real value of "monotonic" timers is that they don't leap
backwards, and preferably don't leap forwards. Whether they are
absolute is of no consequence. I would suggest that the API reflect
this, and that more specific time values be obtained using the proper
raw syscall wrapper (like time.clock_gettime) if required.
time.relative(strict=False)?
The ultimate use of the function name being established is for use in
timeouts and relative timings.
Where an option is present, it disallows fallbacks like
CLOCK_MONOTONIC and other weaker forms:
* time.hardware(fallback=True) -> reflects the source of the timing
impeccably. alerts users to possible affinity issues
* time.monotonic_raw() -> a bit linux specific...
* time.relative(strict=False) -> matches the use case. a warning
could be put regarding hardware timings
* time.monotonic(raw_only=False) -> closest to the existing
implementation. the keyword name i think is better.
More information about the Python-Dev
mailing list