Date: Wed, 29 May 2002 07:10:31 +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: <20020529064206.B22731-100000@gamplex.bde.org> In-Reply-To: <20020528211947.A20393@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 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 > > right by permitting it to be a runtime parameter. This value should > > be <frequency of kernel timecounter> which may be a few billion on > > current machines. This requires clock_t to be much larger than uint32_t > > so that it can represent 24 hours in ticks. clock_t should probably be > > double. > > But to do this would require changing the implementation to use something > other than getrusage() to implement clock() and times(). Wouldn't it be > better to add a non-standard interface for getting the higher resolution > value, instead of being non-compliant? clock() and times() can keep using getrusage() for a while. The important points are to enlarge clock_t and make CLOCKS_PER_SECOND a non-constant so that it can be changed without breaking binary compatibility. BTW, the Linux emulator has several Linux constants for CLK_TCK compiled in. times(3) is is times(2) in Linux, so if Linux changed it then the emulator would need to have even more Linux constants and ifdefs to decide which one to use... > There's currently a discussion on comp.std.c about relaxing the C99 > definition of CLOCKS_PER_SEC back to the C89 definition. I didn't know that C99 changed it. I read com.std.c every week or so. Time to catch up. It all seems to be there... Almost content-free except for the first post :-). Yes, the old definition was better. CLOCKS_PER_SEC is 18.2 in all the versions of Turbo/Burland C that I've looked at (1987-1999), but clock_t is long. Requiring CLOCKS_PER_SEC to have type clock_t breaks this. Requiring CLOCKS_PER_SEC to be a compile-time constant breaks my preferred definition of it as sysconf(...) :-), and is bad for portabilty as discussed in the thread. I suspect that there is a lot of practical code that does stupid things like revaluating CLOCKS_PER_SEC in inner loops, but I think this isn't much of a problem under BSDish system because serious code uses gettimeofday() or getrusage(). > > I actually prefer to let this rot and tell everyone to use clock_gettime(). > > We currently tell everyone to use getrusage(). I used to use gettimeofday() in my clock syscall overhead benchmark, but switched to clock_gettime() a few months ago when I finally got a system with a >= 1GHz clock :-). 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?20020529064206.B22731-100000>