Re: Timers and timing, was: MySQL Performance 6.0rc1

On Sat, 2005-Oct-29 09:38:21 +0200, Poul-Henning Kamp wrote:
>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
...
>
>If we can live with this, there is no problem.

Most applications will do all their timekeeping using a single set of
clock calls so I don't think this is especially serious.  Does POSIX
require any guarantees about (eg) clock_gettime(CLOCK_REALTIME), time()
and gettimeofday() returning identical values?  Can we claim "rounding
and truncation" to explain the discrepancies?

>>It's 
>>gettimeofday() that's the troubling one -- it's widely used to query the 
>>time in applications, and its API suggests microsecond resolution.
>
>And we don't really have a cheap way to do that...

If we did drop the microsecond resolution, we wouldn't be alone - it
used to be fairly common for tv_usec to increment in 1/hz steps.  Even
our manpage states that it might be incremented in ticks rather than
continuously.

-- 
Peter Jeremy