Date: Sun, 4 Dec 2005 12:53:22 -0500 From: Garrett Wollman <wollman@csail.mit.edu> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: current@FreeBSD.ORG Subject: Re: MySQL Performance 6.0rc1 Message-ID: <17299.11538.560643.715262@khavrinen.csail.mit.edu> In-Reply-To: <23153.1130423266@critter.freebsd.dk> References: <20051027140031.L32255@fledge.watson.org> <23153.1130423266@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[Picking up a thread from more than a month ago...] <<On Thu, 27 Oct 2005 16:27:46 +0200, "Poul-Henning Kamp" <phk@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17299.11538.560643.715262>