Timers and timing, was: MySQL Performance 6.0rc1
Peter Jeremy
PeterJeremy at optushome.com.au
Sat Oct 29 01:47:23 PDT 2005
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
More information about the freebsd-current
mailing list