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
