apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: cvs commit: apr STATUS
Date Thu, 11 Jul 2002 23:50:36 GMT

>   +       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.


View raw message