[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