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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
