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 >
