> + others that I haven't checked. In any case, since we use the
> + system's time_t time() function to get the time value everywhere
> + except Win32 w/SYSTEMTIME, we only ever have a resolution of
> + seconds or milliseconds. So, why the hell are we storing usecs?
> + We don't use them. We don't even have display functions for them.
> + We have to do a stupid conversion every time we actually do
> something
> + useful with time in order to support somebody's wet dream of a
> + potentially useful feature? That's crap! This is exactly why
> + I hate portability libraries that aren't based on the demonstrated
> + needs of a specific application.]
Um, Roy? WTF are you talking about?
>From apr/time/unix/time.c:
APR_DECLARE(apr_time_t) apr_time_now(void)
{
struct timeval tv;
gettimeofday(&tv, NULL);
return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
And as for "demonstrated needs," you're thinking too Apache-centric by a
longshot. I very frequently use APR in my research work, which is
graphics-rendering-related (thus, nothing to do with Apache at all). I
*need* microsecond resolution in real time or as close to it as I can get.
Even millisecond resolution usually isn't enough for my timing needs
(think about it -- 60 frames per second means I need timing information at
a very high resolution, since I get a grand total of a whopping 16ms for
each frame, and I have to make decisions on how to spend that time).
Resolution of time only in seconds would do me zero good.
The fact that APR has provided me with a platform-neutral way to get
high-resolution time has been a *huge* boon to my work. While I realize
this is a limited example, the same applies to many other use cases I can
think of.
Stop hand-waving-saying-we're-hand-waving, please. IMO there's definitely
a very valid case for having sub-second time resolution in this
portability library, as getting high-resolution time across platforms is a
*bear* to do yourself.
--Cliff
