MySQL Performance 6.0rc1
wollman at csail.mit.edu
Sun Dec 4 09:54:02 PST 2005
[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
> 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
>> 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  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
> 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
More information about the freebsd-current