Subject: Re: sysconf _SC_CLK_TCK bug?
To: Perry E. Metzger <email@example.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 06/17/2002 15:54:58
On 17 Jun 2002, Perry E. Metzger wrote:
> Ben Harris <email@example.com> writes:
> > In article <firstname.lastname@example.org> you write:
> > >It appears that sysconf(_SC_CLK_TCK) has a bug -- or at least that the
> > >implementation is, er, "deficient".
> > There doesn't seem to be any requirement for it to correspond to any
> > hardware concept, so our behaviour, while strange, is conforming.
> Unfortunately, the call is the only way for applications like ogle to
> guess what the resolution of calls like nanotime is.
Urgh. clock_getres() and clock_gettime() would be more appropriate for
that, but we implement clock_getres() wrongly as well so I can't really
> > Be aware that times() returns its results in _SC_CLK_TCK units, so you need
> > to ensure that it stays in sync.
> Actually, according to the documents, it returns things in the fully
> unrelated CLOCKS_PER_SEC unit.
Are you sure?
# All times are measured in terms of the number of clock ticks used.
and in the APPLICATION USAGE (informative):
# Applications should use sysconf(_SC_CLK_TCK) to determine the number of
# clock ticks per second as it may vary from system to system.
Nowhere does it mention CLOCKS_PER_SEC. The normative text in 1003.1-1996
is identical, and times(3) agrees.
You may be getting confused with clock(), which also uses clock_t, and
_does_ use CLOCKS_PER_SEC units.
> > More awkwardly, 1003.1-1996 says that CLK_TCK and sysconf(_SC_CLK_TCK) must
> I'm basing things on the brand new SuS3 -- i.e the new POSIX (as of a
> few months ago), not the old.
OK. I wasn't sure that the old one could be considered to be
comprehensively dead just yet.
> > be the same, so you'll have to mess around a bit to deal with
> > dynamically-linked applications that have the current value of CLK_TCK
> > burned into them
> I think it is fine to leave them alone. They're no more wrong tomorrow
> than they were today.
Erm, at the moment they work, because our times() agrees that CLK_TCK is
the right unit to use. See lib/libc/gen/times.c. If you change the value
of CLK_TCK used by times(), then you'll break applications compiled with
the old value.
Incidentally, another potential problem if you care about 1003.1-1996 is
that it says that clock_t must be able to hold 24 hours' worth of clock
ticks. This limits you to about 23000 clock ticks per second if it's a
signed 32-bit type (which it is on NetBSD/alpha). This requirement seems
to have been dropped in 1003.1-2001.
Ben Harris <email@example.com>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>