Ben Harris <bjh21@netbsd.org> writes:
> In article <87hek2rhal.fsf@snark.piermont.com> you write:
> >It appears that sysconf(_SC_CLK_TCK) has a bug -- or at least that the
> >implementation is, er, "deficient".
> 
> The definition of a POSIX "clock tick" is:
> # An interval of time; an implementation-defined number of these occur each
> # second.
> <http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html
>  #tag_03_97>
> 
> 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. Thus, if we are
to work properly with such apps, we need to implement things
"correctly" for some value of "correctly".

> >As one can readily see from the standards document, 
> >   http://www.opengroup.org/onlinepubs/007904975/functions/sysconf.html
> >the call should be returning the number of clock ticks per second on
> >the host, but it is instead returning a constant CLK_TCK which is
> >defined in time.h as "100", which is certainly not The Right Thing,
> >especially when HZ is not 100.
> 
> 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.

> 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.

> 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.

> >I propose the following patch, which I have tested, to bring us into
> >conformance. I would also like to know if the CLK_TCK #define in
> >time.h should be removed since it does something horribly spurious.
> 
> Again, if you care about 1003.1-1996 compatibility, it should be kept. 
> 1003.1-1996 says it's allowed to be evaluated at run time, so it can be
> turned into a call to sysconf(_SC_CLK_TCK).

Hmm. That is a possibility I suppose.

--
Perry E. Metzger		perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/