apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: SGI Patch 10xpatch-2.0a6-2: Reduce time resolution to 1 sec
Date Sat, 24 Feb 2001 00:52:56 GMT
From: "Greg Marr" <gregm@alum.wpi.edu>
Sent: Friday, February 23, 2001 4:56 PM


> 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:
> >
> > Dean Commented;
> >
> > > 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.

So we end up with a multitude of representations?  That is more nuts than
having base 10 division and multiplication scattered throughout the code.
 
> Especially since they have to divide it by 1,000,000, not 100,000.

True, that's why there is a macro for the ms value, I believe, and their
should be if there isn't.  Experience shows that folks having to type the
same digit more than twice (or dial on the telephone) get it wrong more
times than not.
 
> >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.

Since the server was overhauled, you could probably find 30 commits fixing
any aspect of the code that has been apr-ized.  The compiler emits warnings
throughout when we are messing this up.

The design flaw was providing the short representation in the first place.
64 bit arithmetic needs 64 bit delta values, and had that been accepted on
day one, those commits need never have happened.

Perhaps there is only one answer to the slop (and we will have slop if we
use seconds or microseconds, take your pick) is to hide this in a structure
and force folks to use inlined/macroized (based on platform) implementations
of the arithmetic, to assure they don't do something foolish.

> ... or when they divided by the wrong number because they dropped a 
> zero.
> 
> I agree that this would be a good change.

I entirely disagree.  That has nothing to do with the definition of time.
If you would like to restate this entire argument on the computational
benefits of seconds, do so.  Time and Date errors happen in any environment
when you don't follow the design.  It doesn't matter

I'm -1 on any change to our apr_time_t data, unless folks want to make this
an abstract type to hide any arithmetic.  void* - void* is safely undefined
just about anywhere, so we could quite reasonably hide this stuff.  I just
feel that it's probably overkill.  I'm entirely in agreement with Bill
Stoddard's earlier comments this evening.


Mime
View raw message