apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@apache.org>
Subject Re: apr_time_t --> apr_time_usec_t
Date Tue, 11 Jun 2002 00:09:45 GMT
On Monday, June 10, 2002, at 04:11  PM, William A. Rowe, Jr. wrote:
> At 05:04 PM 6/10/2002, you wrote:
>> I am tired of seeing this stupid change to the semantics of time_t
>> under Unix continue to cause bugs in every project that uses APR.
>
> I must have missed that discussion traveling.  Pointers please?

Just do a search for 1000000 or USEC in the cvs archives. I've seen at
least two dozen separate bug fixes applied to APR and httpd that were
directly caused by people changing time_t to apr_time_t and expecting
it to work.  The latest one floated by this weekend.  Bad interfaces
are evidenced by repetition of the same bugs over time.

>> apr_time_t must be in seconds.  If folks want APR to keep time in
>> microseconds, then they had bloody well change the type name
>> accordingly.
>
> apr_time_t must nothing :-)  Let's discuss *should(s)*

No.  I will veto the change from time_t to apr_time_t due to misleading
changes in semantics.  I am going back to the state wherein httpd was
robust.  Since my change will both reduce bugs and improve performance,
without sacrificing any known features, there is sufficient justification
for making it in httpd.

You can debate how this should effect APR all you like.  I'd prefer
a solution that is general to APR.  I don't know of any APR client apps
that make use of microseconds other than flood and ab.

> time_t is seconds.  I love the idea of apr_time_usec_t and apr_time_sec_t
> names rather that something as ambigous as apr_time_t (which is 
> misleading,
> I agree.)

Fine, that is one solution.

 > As far as adopting apr_time_sec_t throughout, you may be looking forward
> to your retirement party before a signed 32 bit apr_time_sec_t blows 
> chunks.
> Having coded against Y2K since 1989, I'd absolutely veto this suggestion
> for general adoption.  Specific cases, fine.

time_t is not limited to 32 bits.  I never mentioned 32 bits.  You must
be referring to someone else.  Doing 64 bit divides and multiplies are
bad for performance, but that is done because we are storing microseconds
even though we never use microseconds.  Eliminate the microseconds, or
move it to a separate field, but keep the 64 bits.  I personally think
it a waste of time (no pun intended) to worry about a 32bit time_t
when time_t is only 32 bits on machines that only have a 32bit interface
to their time operations, and hence our clock will still roll-over
regardless of how many extra bits we use to store our copy of time_t.

I will discuss httpd changes on dev@httpd -- this thread was just to
get a little frustration off my chest regarding APR design decisions
that are made based on the theory that they "might some day be needed"
and then never changed (in spite of several requests on my part) based
on the theory that they might break some mythical "user" of APR.  It's
time to get the clue stick out of the closet.  From now on, apr_time_t
is considered harmful.

....Roy


Mime
View raw message