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

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sat, 29 Oct 2005 09:38:21 +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
	124.000020300
					123
	124.000983092
					123
		(hardclock happens)
	124.001020934
					124

If we can live with this, there is no problem.

>Likewise, keeping 
>CLOCK_REALTIME as is is likely OK -- if an application requests it using 
>clock_gettime(), then it is presumably looking for high accuracy.

Yes, I think clock_gettime(CLOCK_REALTIME) should remain unchanged.

>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...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sat Oct 29 2005 - 05:38:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC