Timers and timing, was: MySQL Performance 6.0rc1

[Poul-Henning Kamp]

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.