> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > At 05:05 PM 8/4/2002, Aaron Bannert wrote: > >On Sun, Aug 04, 2002 at 06:29:34PM -0000, [EMAIL PROTECTED] wrote: > > > wrowe 2002/08/04 11:29:33 > > > > > > Modified: include apr_time.h > > > time/unix time.c > > > time/win32 time.c > > > Log: > > > Time in exact ms intervals can be very useful in benchmarking... > this > > > patch defines a general API for doing so if the platform supports > > > toggling the clock resolution. Don't recommend doing so for > HTTPD, > > > but flood and ab should appreciate it. > > > >If APR can't guarantee a certain precision across the board, how will > >that API be useful? > > APR cannot guarantee anything. We have too many platforms. The point > of this API is that win32, perhaps others, have more than one granularity > of time. Your question should be, if we can't guarantee a certain > precision across the board, how are ab or flood useful? I'd argue they > only provide insufficient resolution, and if there is an api to toggle it, > this new function exposes that API.
I disagree. When APR was started, we only provided functions that could reasonably be implemented on _most_ of our platforms. IMHO, if we can find other platforms that can reasonably implement this feature, then we should keep it, but if we can't, then this function should go.
And our API defines time resolution in a 1us units. This function simply guarantees that if a platform can improve it's apr_time_now() resolution -towards- 1us units, than it should do so for the duration of the pool [which will generally be the lifetime of the process, if you call with the base or global pool.]
Great for benchmark timings, worthless for HTTPD.
So, find another place to put this platform specific anomaly, such as a new
argument to the apr_initialize fn [which I REALLY didn't want to change]...
or this fn needs to remain. In case you didn't get the gist, from a performance
perspective it's not a change you want to make for every apr application.
Bill
