Re: MySQL Performance 6.0rc1

[Picking up a thread from more than a month ago...]

<<On Thu, 27 Oct 2005 16:27:46 +0200, "Poul-Henning Kamp" <phk_at_phk.freebsd.dk> said:

>     *	Additional CLOCK_FOO values for various degraded but fast
> 	timestamps.

> Unfortunately, they either force intense versioning of libc or
> application source-code changes, so neither is very desirable.

This option is not as bad as it sounds.  For applications which use
clock_gettime() et al it's a trivial change that can easily be hidden
behind a preprocessor macro (and probably should be anyway, since most
of those applications really want to use something like
CLOCK_MONOTONIC iff it's available).  I wouldn't be averse to
downgrading gettimeofday().

>> Sadly, POSIX doesn't say anything about how applications can express 
>> preferences about the cost and granularity of time measurement.

> Yes, in addition to their other defficiencies [1] the APIs are
> somewhat limited in what they can express.

I've tried to get the Austin Group interested in improving the clock
APIs as a work item.  No such luck, but it can't hurt to try some
more.  What would help greatly would be an actual implementation
(e.g., new clock_xxx() functions and CLOCK_xxx constants) and some
(even simple) applications that can take advantage of it.  These are
within the implementation namespace so there door is wide open in that
respect.

> I've often thought about inventing a new API to solve these problems,
> it doesn't take much to do it right, but I have never carried through
> on it because adding yet another "FreeBSD-propriety" API is not the
> solution we're looking for.

All APIs start out that way; the POSIX people have learned (by doing)
that committee invention is a bad thing, and are rightfully reluctant
to add new interfaces unless they are proven workable by prior
implementation.

-GAWollman