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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4