[Python-Dev] Drop the new time.wallclock() function?
Russell E. Owen
rowen at uw.edu
Thu Mar 15 20:22:03 CET 2012
In article
<EFE3877620384242A686D52278B7CCD3362609 at RKV-IT-EXCH104.ccp.ad.local>,
Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
> What does "jumping forward" mean? That's what happens with every clock at
> every time quantum. The only effect here is that this clock will be slightly
> noisy, i.e. its precision becomes worse. On average it is still correct.
> Look at the use cases for this function
> 1) to enable timeouts for certaing operations, like acquiring locks:
> Jumping backwards is bad, because that may cause infinite wait time. But
> jumping forwards is ok, it may just mean that your lock times out a bit early
> 2) performance measurements:
> If you are running on a platform with a broken runtime clock, you are not
> likely to be running performance measurements.
>
> Really, I urge you to skip the "strict" keyword. It just adds confusion.
> Instead, lets just give the best monotonic clock we can do which doesn"t move
> backwards.
> Let's just provide a "practical" real time clock with high resolution that is
> appropriate for providing timeout functionality and so won't jump backwards
> for the next 20 years. Let's simply point out to people that it may not be
> appropriate for high precision timings on old and obsolete hardware and be
> done with it.
I agree. I prefer the name time.monotonic with no flags. It will suit
most use cases. I think supplying truly steady time is a low level
hardware function (e.g. buy a GPS timer card) with a driver.
-- Russell
More information about the Python-Dev
mailing list