apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@apache.org>
Subject Re: cvs commit: apr STATUS
Date Fri, 12 Jul 2002 01:00:37 GMT
> 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.

Of course I am.  It is still the only application of APR that matters,
by a long shot (SVN uses httpd too).

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

Sounds great.  How about adding a few test cases and finishing the rest
of the time code so that it isn't in a halfway state?

I don't have any problem with APR implementing microseconds.  I have a
problem with APR implementing time-in-seconds as microseconds. Always have.
If you need both, then implement both.

....Roy


Mime
View raw message