apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: cvs commit: apr-site versioning.html
Date Tue, 13 Aug 2002 18:54:22 GMT
On Tue, 13 Aug 2002, Brian Pane wrote:

> Ryan Bloom wrote:
> 
> >On Tue, 13 Aug 2002, Aaron Bannert wrote:
> >
> >  
> >
> >>On Tue, Aug 13, 2002 at 11:15:48AM -0700, Brian Pane wrote:
> >>    
> >>
> >>>I think APR is close to being ready for 1.0.  We still need to
> >>>fix the apr_time_t performance problems (the old 64-bit division
> >>>issue), though.
> >>>      
> >>>
> >>Can we plan on doing this for 1.1 once we have the versioning in
> >>place and a solid release?
> >>    
> >>
> >
> >I have a better question.  Has anybody come up with a design that we can
> >agree on for this?  If there is no design, then we really can't solve the
> >problem quickly.  The last I saw about this issue, nobody agreed on how to
> >fix it, or even that there was a real problem.
> >
> 
> There were a few promising solutions, but all of them had one
> technical problem or another.  Basically, each of the proposals
> performed well for some set of operations but poorly for at least
> one other operation that might be important to some application.
> 
> Toward the end of that last round of discussions, I thus proposed
> that APR get out of the business of managing microseconds:
> 
> http://marc.theaimsgroup.com/?l=apr-dev&m=102678180413988
> 
> I'm interested in hearing people's comments on that proposal.

Doesn't that completely ignore Cliff's message early in this thread that
specifically stated that he needed microsecond resolution?

I continue to state that APR's time format should stay as it is.  If you
want seconds, use time_t.  The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value, which would mean that any
arithmetic on the intervals would be faster.  Apache, doesn't want (or
need) microsecond resolution, so it should use time_t, which
co-incidentally is now very easy to translate into an apr_interval_time_t
very quickly.  Since most, if not all, of the apr_functions should be
using apr_interval_time_t for the arguments, converting types should be
minimal.

Rya


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------


Mime
View raw message