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.
K
-----Original Message-----
From: python-dev-bounces+kristjan=ccpgames....@python.org
[mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of
Nadeem Vawda
Sent: 14. mars 2012 14:18
To: Matt Joiner
Cc: Antoine Pitrou; Guido van Rossum; python-dev@python.org
Subject: Re: [Python-Dev] Drop the new time.wallclock() function?
+1 for time.steady(strict=False).
On Wed, Mar 14, 2012 at 7:09 PM, Kristján Valur Jónsson <krist...@ccpgames.com>
wrote:
>> - By default, it should fall back to time.time if a better source is
>> not available, but there should be a flag that can disable this
>> fallback for users who really *need* a monotonic/steady time source.
> As pointed out on a different thread, you don"t need this "flag" since the
> code can easily enforce the monotonic property by maintaining a static value.
> This is how we worked around buggy implementations of QueryPerformanceCounter
> on windows ().
> K
That's fine if you just need the clock to be monotonic, but it isn't any help
if you also want to prevent it from jumping forward.
Cheers,
Nadeem
_______________________________________________
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/kristjan%40ccpgames.com
_______________________________________________
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
