You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <dr...@jetnet.co.uk> on 2002/07/16 01:36:22 UTC
Earth to APR????
Can we all come down off the ceiling for a bit and get our feet back on the
ground?
I can't help but wonder why we are making this whole thing so complicated
when people have been using computers and libraries using time quite happily
for a number of years without getting as involved as this has gotten. But
then maybe I've borrowed some of Cliff's crack?
BTW, this is getting embarrassing to watch - please can we bring this to a
head somehow?
david
Re: a new proposal Re: Earth to APR????
Posted by 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
RE: a new proposal Re: Earth to APR????
Posted by 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
>
a new proposal Re: Earth to APR????
Posted by Brian Pane <br...@apache.org>.
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: Earth to APR????
Posted by Brian Pane <br...@apache.org>.
Do you have any specific solution in mind?
--Brian
David Reid wrote:
>Can we all come down off the ceiling for a bit and get our feet back on the
>ground?
>
>I can't help but wonder why we are making this whole thing so complicated
>when people have been using computers and libraries using time quite happily
>for a number of years without getting as involved as this has gotten. But
>then maybe I've borrowed some of Cliff's crack?
>
>BTW, this is getting embarrassing to watch - please can we bring this to a
>head somehow?
>
>david
>
>
>
>
Re: Earth to APR????
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 16, 2002 at 12:36:22AM +0100, David Reid wrote:
> Can we all come down off the ceiling for a bit and get our feet back on the
> ground?
This coming from our resident pilot. :)
(+1)
-aaron
Re: Earth to APR????
Posted by Brian Pane <br...@apache.org>.
William A. Rowe, Jr. wrote:
> At 06:36 PM 7/15/2002, David Reid wrote:
>
>> Can we all come down off the ceiling for a bit and get our feet back
>> on the
>> ground?
>>
>> I can't help but wonder why we are making this whole thing so
>> complicated
>> when people have been using computers and libraries using time quite
>> happily
>> for a number of years without getting as involved as this has gotten.
>> But
>> then maybe I've borrowed some of Cliff's crack?
>>
>> BTW, this is getting embarrassing to watch - please can we bring this
>> to a
>> head somehow?
>
>
> Would my unequivocal veto of any change to apr_time_t help?
Based on the data that we have so far, it wouldn't help.
The current apr_time_t implementation isn't adequate for
use in the httpd, based on the performance profile data
that shows the 64-bit divisions to be a bottleneck.
It would be nice to say, "no problem, we'll just extract
the seconds right after we look up the request_time, and
we'll use the seconds value instead of the apr_time_t
for everything after that." But that won't fix the
problem. We deal with multiple timestamps in a typical
request, not just r->request_time, and they all incur
the 64-bit division costs. (For example, we need to
format the mtime of the delivered file for use in the
last-modified header. APR does a 64-bit multiplication
to pack the time into an apr_time_t, and the httpd then
has to do a 64-bit division to unpack the seconds field.)
--Brian
Re: Earth to APR????
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:36 PM 7/15/2002, David Reid wrote:
>Can we all come down off the ceiling for a bit and get our feet back on the
>ground?
>
>I can't help but wonder why we are making this whole thing so complicated
>when people have been using computers and libraries using time quite happily
>for a number of years without getting as involved as this has gotten. But
>then maybe I've borrowed some of Cliff's crack?
>
>BTW, this is getting embarrassing to watch - please can we bring this to a
>head somehow?
Would my unequivocal veto of any change to apr_time_t help?
I believe the last week has proved one thing very clearly; that there
are dozens of ways to implement time. And APR has already
wisely chosen the most appropriate representation.
Bill
RE: Earth to APR????
Posted by Ryan Bloom <rb...@covalent.net>.
++1!
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: Monday, July 15, 2002 4:36 PM
> To: APR Dev List
> Subject: Earth to APR????
>
> Can we all come down off the ceiling for a bit and get our feet back
on
> the
> ground?
>
> I can't help but wonder why we are making this whole thing so
complicated
> when people have been using computers and libraries using time quite
> happily
> for a number of years without getting as involved as this has gotten.
But
> then maybe I've borrowed some of Cliff's crack?
>
> BTW, this is getting embarrassing to watch - please can we bring this
to a
> head somehow?
>
> david
>
>
Re: Earth to APR????
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 16 Jul 2002, David Reid wrote:
> BTW, this is getting embarrassing to watch - please can we bring this to a
> head somehow?
Party pooper. ;)