In article <efe3877620384242a686d52278b7ccd3362...@rkv-it-exch104.ccp.ad.local>, Kristján Valur Jónsson <krist...@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
_______________________________________________ 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
