apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <gr...@alum.wpi.edu>
Subject Re: SGI Patch 10xpatch-2.0a6-2: Reduce time resolution to 1 sec
Date Fri, 23 Feb 2001 22:56:51 GMT
Copied to the APR list, since this is an APR type.  The original 
proposal by Roy was to make apr_time_t a structure containing a 
time_t for seconds, and an int for microseconds, since many/most 
users of this type only need 1-second resolution, and the ones that 
need microsecond resolution need microseconds as a separate parameter.

At 02:37 PM 02/23/2001 -0800, Roy T. Fielding wrote:
> > time arithmetic is way easier on a single scalar than it is on 
> multiple
> > scalars.  contrast:
> >
> >       diff = now - then;
> >
> > vs.
> >
> >       diff.sec = now.sec - then.sec;
> >       long tmp = (long)now.usec - (long)then.usec;
> >       if (tmp < 0) {
> >               tmp += 1000000;
> >               --diff.sec;
> >       }
> >       diff.usec = tmp;
>
>No, contrast
>
>      diff = apr_time_interval(then, now);
>
>apr_time_t is a data type.  The above can be a macro if you want it 
>fast, but the point is that every single client of APR should not be 
>dependent on knowing the exact representation of time and 
>remembering that they have to divide it by 100000 just to get 
>something useful.

Especially since they have to divide it by 1,000,000, not 100,000.

>I have seen well over 30 commits fixing bugs specifically due to 
>this notion that you can subtract one unknown scalar from another 
>unknown scalar and still remain within the bounds of some other 
>unknown scalar.  And another 20 or so fixing places where someone 
>forgot to divide by or multiply by 100000.

... or when they divided by the wrong number because they dropped a 
zero.

I agree that this would be a good change.

-- 
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"


Mime
View raw message