From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 7 23:05:34 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A971416A4CE; Mon, 7 Mar 2005 23:05:34 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1049943D1D; Mon, 7 Mar 2005 23:05:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j27N5WA6012401; Tue, 8 Mar 2005 10:05:32 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j27N5TMq022419; Tue, 8 Mar 2005 10:05:31 +1100 Date: Tue, 8 Mar 2005 10:05:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <1924.1110230810@critter.freebsd.dk> Message-ID: <20050308092209.T42635@delplex.bde.org> References: <1924.1110230810@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Matthew Soffen cc: freebsd-bugs@FreeBSD.org cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/78537: times(2) not functioning per the Posix spec X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 23:05:34 -0000 On Mon, 7 Mar 2005, Poul-Henning Kamp wrote: > In message <20050308072635.G42370@delplex.bde.org>, Bruce Evans writes: >> 3. The return value might be non-strictly monotonic. Since the resolution >> of clock_t is too small to be useful for almost everything (still 1/128 >> seconds despite hat resolution being too small to be useful 10+ years >> ago when meachines were 1000+ times slower), the return vaue of times(2) >> is very likely to be the same for successive calls. > > I think one would be forced to do modulus-2 circular arithmetic like > on sequence numbers in various protocols. Do you mean that with a resoultion large enough to give strict monotonicity, wraparound would be much more likely and complications to handle it would be essential? > Isn't there a standards requirement for the resolution to be 1000000 > these days ? (See tail end of clock(3) manual page). clock(3) documents a requirement for CLOCKS_PER_SEC to be precisely 1000000 in some standards. This is a bug in these standards. clock(3) mentions SUSv2 and POSIX but isn't very clear about the latter. The current POSIX standard makes it clear that this bug is only in the XSI extension. Anyway, this doesn't affect times() since the units for times() are sysconf(_SC_CLK_TCK), not CLOCKS_PER_SEC. FreeBSD still hasn't caught up with POSIX's removal of the bogus interface CLK_TCK. FreeBSD's implementation of CLK_TCK as a compile-time constant is one of 2 things that inhibit giving times() and friends enough resolution for these interfaces to actually be useful. The other one is: - clock_t is 32-bits on all arches, so the resolution can't be high enough without breaking the range requirement. IIRC, clock_t is supposed to have a range of at least 24 hours -- this limits sysconf(_SC_CLK_TCK) to <= 49710, so in particular it can't equal CLOCKS_PER_SEC on XSI systems with 32-bit clock_t's. CLK_TCK is also a problem for emulators. In the Linux emulator, times() is in the kernel and it has the same code and thus bugs as the library version except: - it already uses a monotonic clock (microuptime()) - it has different too-small values for CLK_TCK (100 for i386's and 1024 on alphas) - FreeBSD can't fix it until Linux does. Bruce