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: cvs commit: apr STATUS
Date Fri, 12 Jul 2002 02:19:54 GMT
>   I will say the very same thing Ryan did several weeks [months?] ago.
> Where were you for the last two years?

Complaining about how fucked up the design decisions were for apr_time_t.
Its in the archives.  People didn't want to deal with it before due to
more pressing concerns.  2.0 is now out, so there are no more excuses.

>   The questions on the table in APR is;
>     1. are we the special interest of httpd alone?  Are we their 
> sub-project?

Irrelevant.  If you want httpd to use APR, then it had better not make 
worse for no good reason.  If there is a reason, then I want it documented
in the code.  If not, if it is just the whim of some folks using APR, then
I will fork the httpd project away from APR.  Nobody else has to follow the
redesign, but then at least I'll be satisfied in trying.  With the
binary microseconds change we have finally tackled the performance
concern to at least a level of reasonable trade-off, albeit undocumented.
Now we just need to solve the problem of all of the inconsistent code
due to people assuming (or never fixing) apr_time_t == time_t.

>     2. was this already thought out and debated, and this design won?

No.  It was put off until we were willing to tackle performance issues.
That time is now.

>     3. Is a veto of long existing code within APR allowed by protocol?

If there is a good reason, yes.

>     4. What is an appropriate name?  This A. depends on
>       a. Should the usec or busec be a strong contract with the 
> programmer?
>       b. Is it the only time representation internal across APR?
>   My answers?
> 1. No.
> 2. Yes
> 3. No
> 4. busec or butime, with a strong contract, and the only representation.
>   Were there bugs moving to APR?  Yes.  Was sec v.s. finer granularity
> a significant debate?  Yes.  Debated over and over.  Is apr_time_t a 
> therefore
> misleading identifier?  Probably, I concede that point to you and aaron.

It isn't a debate.  It is a point of fact that it causes bugs to be
introduced and reintroduced, over and over again.

>   We are not debating if we will revert to the old time_t values.  That 
> was said
> and done way too long ago, and if you choose not to be a party to that 
> whole
> bit, or register your vetos then, it is WAY to late.  The code exists, 
> now you
> can put a whole-other vote to the list.  Fine.  Don't commingle your 
> temper
> tantrum with a worthwhile vote on a significant issue.  Keep to the 
> Question.

The way you phrased the question was so hopelessly biased that I felt it
necessary to respond with content.  I got tired of the changing question
and put the rationale instead.  If you don't agree with my rationale, then
please explain why applications that only use second resolutions should
be required to operate on microseconds.  Furthermore, given that we can't
provide actual microsecond resolution in a cross-platform way, isn't it
doing harm to suggest to the application that we can?

>   I'm not about to rip out all your off-topic comments, although I'm sure 
> others
> are more than happy to.  Can we trim it down to the question and please
> leave the tm structs out of this specific vote?  I'll address those 
> questions here,
> not in STATUS; feel free to add another [seperate] vote:

The tm struct is the way all of the operating systems have decided this
question in the past.  That balances the needs of second-based
time calls with microsecond-based time calls.  That's why the OS people
define their own structures that way.  busecs are another solution, one
that will be better for 64bit machines but worse for 32bit *shrug*, but
we still don't provide all of the routines needed by clients to
manipulate these things, and we still have no answer for apr_interval_time.

>> fielding    2002/07/11 17:30:59
>>          [wrowe: deltas require NO definition of the scale.]
>>   +        [fielding: That's nonsense. What does overflow mean?  What 
>> are you
>>   +         going to do when you print?  How do you interface with other 
>> library
>>   +         routines?  Scale always matters for scalars.]
> Not if they are assured to contain enough precision, which apr_time_t 
> does.
> Not for simple deltas of start and end times, which is what matters most.
> But I'm in favor of a strongly defined contract for scale with the user,
> although others on the list differ.
>>           a dead horse... compositing and breaking apart for each simple 
>> deltas
>>           (the most common case) is too costly.  Scalars are the only 
>> clean
>>           answer - and you do not need to know scale to do 
>> addition/subtraction.]
>>   +
>>   +        [fielding: Dean argued that in general.  I argue that httpd 
>> never
>>   +         does time arithmetic other than in seconds and 
>> second-comparisons.
>>   +         Microseconds are therefore harmful to httpd.]
> httpd is but one client, and they have participated since day one.  There 
> is a
> tradeoff, and the httpd-2.0 developers were willing to make that trade.  
> End of
> debate, it's been said and done long ago.
> And you are choosing to ignore third party modules entirely, I note.

No, it is the third party modules that are still using apr_time_t as 

>>                in addition to seconds.  Why do you want to throw away the
>>                microseconds?!!]
>>   +              [fielding: Sorry, I missed them:
>>   +                  86 calls to apr_time_now()
>>   +                  32 calls to time()
>>   +               +1 to making time consistent.]
> ++1 and amen to killing time() calls.
>>   +     [fielding: 1. POSIX requires it to be long, so largest native 
>> int.
>>   +       2. Microsoft claims otherwise, but it is still vaporware 
>> anyway.
>>   +       3. POSIX always stores them as separate integers.
>>   +       4. Benchmarks are meaningless unless they average over hundreds
>>   +          of requests, which requires double floats (not time 
>> intervals).
>>   +       5. +1 for using struct tm everywhere.
>>   +       6. No.]
> The long type on Win64 is also 32 bits.  Yes, it's bogus, and I'm not even
> going to try to defend it.  If you don't want to code to it, fine, but 
> APR will
> support it.
> Benchmarks don't need to perform every calculation as long floats, 
> especially
> while collecting data [during timing, prior to processing.]  Your argument
> doesn't hold, and several folks have already raised other examples besides
> benchmark deltas.

No, time on computers doesn't work that way.  You can't add a whole bunch
of individual time calls and expect to have a reasonable answer down to
the microseconds -- the OS does not promise to update the microsecond
field every microsecond (it isn't even available on win32).  The 
field is worthless outside of the kernel networking routines.  flood and
ab need to take start and stop times, subtract to get an interval, and
divide by number of repetitions.  Hence, they are not examples.

> And finally, veto on struct tm.  For all the well reasoned arguments Dean
> made two years ago.  But add a new vote if you like, separate from the
> naming debate.

They are the same debate until apr_time_t's name is changed.  They only
become separate issues after that has been done.


View raw message