Re: a new proposal Re: Earth to APR????
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: Earth to APR????
++1! Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: David Reid [mailto:[EMAIL PROTECTED] 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????
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????
Cliff Woolley wrote: 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. ;) The devil's in the details :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
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: Earth to APR????
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????
William A. Rowe, Jr. wrote: Would my unequivocal veto of any change to apr_time_t help? I think the key point, IMO, is that we need to speed it up. If that requires changes, so be it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
RE: a new proposal Re: Earth to APR????
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 [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Brian Pane [mailto:[EMAIL PROTECTED] 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
