RE: a new proposal Re: Earth to APR????

[Ryan Bloom <rb...@covalent.net>]

I'll say it again.  Leave apr_time_t alone.  If a program wants 1 second
resolution, then they should be using time_t.  apr_time_t specifically
provides microsecond resolution.

Different solutions for different problems.   :-)

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane [mailto:brianp@apache.org]
> Sent: Monday, July 15, 2002 5:35 PM
> To: APR Dev List
> Subject: a new proposal Re: Earth to APR????
> 
> Actually, now that I think about it, I have a solution
> in mind: we (APR) should get out of the business of
> providing microsecond time manipulation.
> 
> Here's my rationale...
> 
> What added value can APR provide to applications that need
> to work with time?
>    - Getting the current time in a portable manner?  Yes.
>    - Converting timestamps to date/time form in a portable
>      manner?  Yes.
>    - Doing arithmetic on times?  Not really.  Every solution
>      we've found for representing a microsecond-resolution time
>      has a performance tradeoff somewhere: either in extracting
>      seconds (current apr_time_t), or in extracting microseconds
>      (busec representation), or in addition and subtraction
>      (struct representation).  Which of these operations can we
>      afford to make slower in order to speed up the other ops?
>      I don't know.  It depends on the application.
> 
> Based on these observations, I think it's important that APR
> be able to provide a portable way to look up the current time
> with microsecond resolution, but APR need not do all the rest
> of its time operations in microseconds.
> 
> Here's a design that I think would be a reasonable compromise:
> 
>    - apr_time_t becomes a 64-bit uint representing seconds
>      since the epoch.  (Maybe it's typedef'ed to time_t.  Maybe
>      not.  Let's worry about that *after* we figure out the
>      desired semantics.)
> 
>    - apr_time_now() returns a time_t, but it also returns
>      the microseconds as a separate value for apps that need
>      them:
>          apr_status_t apr_time_now(apr_time_t *sec, apr_uint32_t
*usec);
>      Note: We could also keep apr_time_now() unchanged and add a
>      different function that would provide seconds and microseconds.
>      There are pros and cons for both.
> 
>    - All the time-maniuplation functions that currently use
>      apr_time_t continue to use apr_time_t.  (As far as I can
>      tell, none of them really need microseconds.)
> 
>    - Interval times are expressed as an integer count of microseconds.
>      (We *might* want to let apr_poll() take an integer count of
> milliseconds
>      to avoid a division by 1,000, since poll is such an important
special
>      case.)
> 
> With this model, we can add one more field to the httpd's request_rec
> to hold the microseconds part of the request_time.  The httpd core
won't
> care about it, but custom modules that need more granular time (e.g.,
for
> special-purpose logging or session ID generation) will have access to
it.
> 
> Apps that need to work with microsecond resolution can choose their
own
> time representation, based on whatever is best suited to the needs of
> the app: structure, binary microseconds, even convert to
floating-point.
> 
> --Brian
> 

Re: a new proposal Re: Earth to APR????

[Brian Pane <br...@apache.org>]

Ryan Bloom wrote:

>I'll say it again.  Leave apr_time_t alone.  If a program wants 1 second
>resolution, then they should be using time_t.  apr_time_t specifically
>provides microsecond resolution.
>

That's not a valid solution.  Even apps that need only
1-second resolution end up having to work with apr_time_t
because APR uses it for things like file stat times and
apr_rfc822_date().  Not that those parts of APR have any
real need for microsecond resolution, either--but they
force the app to use microseconds anyay.

--Brian