[uClibc] clock() for long-running process

[Manuel Novoa III]

On Sun, May 09, 2004 at 10:12:20PM +0900, Atsushi Nemoto wrote:
> Thank you for detailed explanation.
> 
> >>>>> On Sat, 8 May 2004 16:32:40 -0600, mjn3 at codepoet.org (Manuel Novoa III) said:
> mjn3> It would work as expected during the first 2147 seconds of _cpu_
> mjn3> time (not wall clock time) used by the process.  After that, it
> mjn3> would wrap in a way you apparently wouldn't expect.  But then,
> mjn3> you're making unjustified assumptions about what it should do in
> mjn3> that case because the behavior is implementation defined.
> 
> Yes, I agree to you that I'm making an implementation-dependent
> assumption.  My assumption is that clock() return large negative
> number (not zero) after the "wrap".  I feel this is very natural.
> 
> mjn3> Personally I thought it was better to return (clock_t)(-1) if
> mjn3> wrapping was detected, since that seems most consistent with the
> mjn3> definition.  In fact, I think I'll go back to that approach
> mjn3> unless someone can give me a good reason not to.
> 
> Though I prefer non-masked implementation, I think the old
> implementation is better than the current one.  The current one might
> trigger very-hard-to-find bugs if clock() abused.  "Incompatible with
> glibc ALWAYS AFTER 2147 seconds" will be better than "Incompatible
> with glibc ONLY WHEN clock() wraps" to find those abuse.
> 
> mjn3> Besides, you really shouldn't be using clock() to calculate
> mjn3> elapsed cpu time when times() is available.  The X/Open System
> mjn3> Interfaces Extension mandates that clock() values be scaled to
> mjn3> millionths of a second, which limits its usefulness on 32 bit
> mjn3> systems for long-running apps.
> 
> I agree.  But I think there are many programs using two clock() call
> to calclate elapsed time ...

Thought about it some more and decided to make clock() behavior a build
configuration option.  It will either measure absolute cpu time until
reaching overflow and then return (clock_t)(-1) after, or it will
emulate glibc behavior for applications wanting to measure elapsed
times by taking differences.  I still think that latter is bad practice
however, as programs doing this are relying on implemenatation defined
behavior.

Manuel