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 18:16:42 GMT
At 12:29 PM 7/12/2002, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> >
> > 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.
>Some number of seconds does NOT indicate an interval.  Also, why is that
>in seconds all of a sudden?  Our current apr_interval_time_t are in

I said, apr_buseconds_t.  Meaning an arbitrary number of binary microseconds.
And some number of binary microseconds can translate into a timeout or any
other interval of time.

I'm really confused here; there are two principal expressions of time.  One 
is not
anchored to any specific epoch; that's a delta.  One is anchored to a specific
epoch, such as 1/1/1970.

>Can we start this conversation over completely?  Currently we are
>arguing over names for a new type, but I don't think we actually know
>the problem that we are trying to solve.
>If it is just performance, then keep the current name.  Add a versioning
>component to APR, and force people to look at their code by using the
>versioning component.

That is your opinion.  There are other opinions expressed on the list.
Their arguments have equal merit.

>If it is confusion with time_t, then IMNSHO, that is a bogus argument.
>The bugs that were in Apache were there because nobody ever looked at
>the code, it was just assumed that it was correct.  Anybody writing code
>from scratch shouldn't have the problem.

No, folks will have that problem if they've coded against ANSI/POSIX/C99
for years.  Adding apr_busec_time_t and apr_busec_interval_t [or whatever
the f we decide to name them] absolutely dictates that these are not your
Grandpa's time_t units.


View raw message