Date: Mon, 07 Mar 2005 22:26:50 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/78537: times(2) not functioning per the Posix spec Message-ID: <1924.1110230810@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 08 Mar 2005 08:21:01 %2B1100." <20050308072635.G42370@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050308072635.G42370@delplex.bde.org>, Bruce Evans writes: >2. The return value shouldn't be, but is under FreeBSD, non-monotonically > increasing. This might be the bug that you mean. The return value > should track a monotonic clock, one that is actually useful like > CLOCK_MONOTONIC, but it actually tracks CLOCK_REALTIME. This is not > a serious bug. Much more than times(2) breaks if CLOCK_REALTIME is > allowed to to go backwards. This is actually the item we talked about. I will fix this to use CLOCK_MONOTONIC. And yes, we should fix all the things that don't like CLOCK_REALTIME to reflect realtime. >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. Isn't there a standards requirement for the resolution to be 1000000 these days ? (See tail end of clock(3) manual page). >4. The return value might be non-unique across processes, even on non-SMP > systems with processes making strictly ordered calls to times(), since > POSIX permits even the return value to be relative to the start of the > process so as to reduce the overflow possibilities for the return value. I don't think we want to go that way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1924.1110230810>