misc/78537: times(2) not functioning per the Posix spec
phk at phk.freebsd.dk
Mon Mar 7 21:26:55 GMT 2005
In message <20050308072635.G42370 at 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 at 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.
More information about the freebsd-bugs