Date: Fri, 31 May 2002 02:59:15 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tony Finch <dot@dotat.at> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization Message-ID: <20020531024719.V29640-100000@gamplex.bde.org> In-Reply-To: <20020530144448.C621@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 May 2002, Tony Finch wrote: > On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > > On Tue, 28 May 2002, Tony Finch wrote: > > > > > I noticed that clock(3) currently violates a requirement of POSIX > > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > > are inconsistent and somtimes different from what is in clocks(7). > > > > That is only in a (broken) XSI extension. "Fixing" this would mainly > > break binary compatibility since it would change from one historical > > wrong value to another (128 -> 1000000). The first C standard got this > ... > Hmm, I've been thinking about this a bit more. Does FreeBSD actually > keep the necessary statistics at that resolution? As far as I can > tell it is done internally at microsecond resolution. It does now, more or less. Process times are stored in struct bintime in -current. struct bintime has a resolution of 2^-64 seconds. User, sys and interrupt times are the process time split up statistically (so their accuracy is much lower than the resolution). This only affects getrusage() and similar interfaces. clock() could use timecounters directly and get the 2^-64 resolution, but there is currently no syscall for this. clock_gettime() is closest. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020531024719.V29640-100000>