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 01:05:18 GMT

   I will say the very same thing Ryan did several weeks [months?] ago.
Where were you for the last two years?

   The questions on the table in APR is;

     1. are we the special interest of httpd alone?  Are we their sub-project?

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

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

     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.

   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.

   I'm not about to rip out all your off-topic comments, although I'm sure 
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:

>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.

>          [wrowe: read code.]
>   +        [fielding: I read it.  I know exactly which functions from httpd
>   +         that I wrote were subsequently broken when they were moved 
> into APR.]

Rude comment, my bad.  Already dropped from CVS.

>                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.

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.

View raw message