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: cvs commit: apr STATUS
Date Fri, 12 Jul 2002 17:09:11 GMT
At 07:22 PM 7/11/2002, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
> >
> > >Not quite opaque in that you can still compute deltas via a
> > >subtraction, but that to understand the quantities, you must place
> > >it through a function/macro.  Brian has already converted httpd
> > >to this model.  -- justin
> >
> > OK... after much hand waving today... #apr channel folks have come
> > up with an interesting idea that might make all happy.
> >
> > IF we adopt apr_butime_t to represent a time (epoch 1.1.1970) and
> > also adopt apr_busec_t to represent any interval, timeout or other
> > delta (not rooted to an epoch) ... both declared as 64bit values,
>would
> > that satisfy everyone?
>
>No.  The interval time needs to be called out as interval time, or you
>haven't solved the problem that type was intended to solve.  Second, the
>names are still horrible, I REALLY hate the busec in the name, because I
>don't think _time_ when I see busec.

Then how about apr_buseconds_t?  This makes it absolutely clear that the
type contains some number of buseconds [whatever those are... open the
doxygen pages... ah... +/-number of binary microseconds.]  But the fact
is the type is clearly some number of seconds, therefore an interval.

apr_butime_t, or apr_busec_time_t is a 'Time' in the classic sense, the
number of bu's or busec's measured from a defined epoch.

That seconds represents an interval of seconds is redundant.

That the other type represents a 'Time' must continue to be clear.

Bill



Mime
View raw message