Timers and timing, was: MySQL Performance 6.0rc1

[John-Mark Gurney]

Poul-Henning Kamp wrote this message on Sat, Oct 29, 2005 at 09:38 +0200:
> In message <20051029005719.I20147 at fledge.watson.org>, Robert Watson writes:
> 
> >It strikes me that replacing time(3) with something that retrieves 
> >CLOCK_SECOND shouldn't harm time(3) semantics.
> 
> It will mean that time(3) is can do minor (~1/hz) timetravel relative
> to the other calls:
> 
> 	clock_gettime()			time(3)
> 
> 	123.999999123			
> 					123
> 	124.000000234
> 					123
> 		(hardclock happens)
> 	124.001020934
> 					124
> 
> If we can live with this, there is no problem.

This also gets into the question how do you round a second? :)  I think
this is fine, or make the leap to 124 on the hardclock before we hit
124... either way, the error introduced is much less than the acuracy
returned by times, and should be safely ignored...  (and the delay in
change is balanced out by the previous delay)...

If you cared that much that you were .001 seconds after 124, you'd be
using a more acurate clock...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."