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 [SUMMARY] time discussion
Date Fri, 12 Jul 2002 19:09:48 GMT
At 01:47 PM 7/12/2002, David Reid wrote
>Can someone simply restate what issue needs fixing. No more hand waving or
>IRC chats, a simple email explaining the issue and what needs fixed.

I will try to do so in a fair and balanced way;


I. We represent all time quantum in the same scale throughout APR.  That
    scale is in microseconds.

II. Performance is an issue, we are attempting to reclaim CPU cycles lost
     converting, especially between seconds and microseconds, both internally
     and externally (by other apps.)

III. The existing name is an issue to Roy and others who are confused by the
      similarity between apr_time_t and time_t (in the ANSI/POSIX definitions.)

IV. Without sacrificing resolution, I put forward a proposal that we use
     a binary representation of microseconds.  Mr. Stoddard has determined
     that the binary representation we presented does reduce the overall cpu
     instructions and clock cycles in httpd request processing, as expected.

V. Aaron and others submit that we should change the name of the type
    if we change the scale, to assure our APR library users aren't tripped up
    by casual msec = t / 1000 computations in their existing code.  This just
    happens to coincide with Roy's concerns in (III.) above.

VI. Brian and others have asked that we have an undefined scalar value
     [with no contract to the users about it's representation.]  Roy and others
     object, due to overflow and range considerations, and binary compatibility
     considerations [as it's all in macros that aren't updated by new 
binaries].

VII. Ryan and others submit that we need two types, in fact; one absolute
      measure (from epoch 1.1.1970) and one 'interval' or 'delta' that 
represents
      a span, rather than a time.  This is the case in APR today.

VIII. From all of the above came the original discussion of naming.  Ryan and
       others believe we should not change the name of the type, whatsoever.
       The sub-argument is between a strongly defined name contract, e.g.
       busec in the identifier, or a completely ambigious name with no contract
       of the scale's unit.

IX. Roy's original comments yesterday went back to item (II.) above, and
     reintroduced to the optimization discussion the options of either using
     seconds to those apr functions that don't need precision, and/or 
replacing
     our time definition with a structure (seperate seconds and useconds 
fields.)
     These options were debated/voted upon several times before on the APR 
list.

I hope this is a balanced and fair summary of the discussion to date.
My unbalanced opinions are a topic for another post.

Bill



Mime
View raw message