Scott wrote: << The Boost implementation can be summarized as: system_clock: mac = gettimeofday posix = clock_gettime(CLOCK_REALTIME) win = GetSystemTimeAsFileTime steady_clock: mac = mach_absolute_time posix = clock_gettime(CLOCK_MONOTONIC) win = QueryPerformanceCounter high_resolution_clock: * = { steady_clock, if available system_clock, otherwise } >> I read again the doc of the QElapsedTimer class of the Qt library. So Qt and Boost agree to say that QueryPerformanceCounter() *is* monotonic. I was confused because of a bug found in 2006 in Windows XP on multicore processors. QueryPerformanceCounter() gave a different value on each core. The bug was fixed in Windows and is known as KB896256 (I already added a link to the bug in the PEP).
I added a time.hires() clock to the PEP for the benchmarking/profiling use case (...)
It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.try_monotonic() suitable for this usecase?
If QueryPerformanceCounter() is monotonic, the API can be simplified to: * time.time() = system clock * time.monotonic() = monotonic clock * time.hires() = monotonic clock or fallback to system clock time.hires() definition is exactly what I was trying to implement with "time.steady(strict=True)" / "time.try_monotonic()". -- Scott> monotonic_clock = always goes forward but can be adjusted Scott> steady_clock = always goes forward and cannot be adjusted I don't know if the monotonic clock should be called time.monotonic() or time.steady(). The clock speed can be adjusted by NTP, at least on Linux < 2.6.28. I don't know if other clocks used by my time.monotonic() proposition can be adjusted or not. If I understand correctly, time.steady() cannot be implemented using CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted? Does it really matter if a monotonic speed is adjusted? Victor