misc/78537: times(2) not functioning per the Posix spec

[Poul-Henning Kamp]

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.