[Python-Dev] Drop the new time.wallclock() function?

[Kristján Valur Jónsson]

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.com at python.org [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Nadeem Vawda
Sent: 14. mars 2012 14:18
To: Matt Joiner
Cc: Antoine Pitrou; Guido van Rossum; python-dev at 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 <kristjan at 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 at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com