On Thu, Aug 4, 2011 at 4:01 PM, Dave Hart
<hart@xxxxxxx> wrote:
On Thu, Aug 4, 2011 at 18:36 UTC, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> Hmmm. So as near as I can tell, coming out of this whole discussion, I
> can see a few options for Libevent 2.1:
>
> * Make no changes in the code, but suggest to people that they should
> be using EVENT_BASE_FLAG_NO_CACHE_TIME if they are running on a
> platform where time checking is very quick and they care about very
> accurate timing.
>
> * Do a slightly inaccurate guess about what operating system types
> we're on, and always disable time cacheing on places like Linux/OSX.
> This will create problems like Nicholas mentions above.
>
> * Probe somehow (probably at runtime) to determine whether we're
> someplace that has fast time checking or not.
>
> Option 1 requires no code changes; option 2 is easy; option 3 will
> mean more work tracking down which versions of what are fast, and
> figuring out how to probe correctly, and is more work than I know if I
> can do personally on this.
Option 3 seems like the only sane approach to attempting to
heuristically decide whether or not to cache time-of-day.
Configure-time checks could mislead, as the runtime system may have
binary-compatible but very different behavior, such as Linux due to
different underlying timesource selection.
I'm not sure what you mean about tracking down which versions of what
are fast, though. ÂCan't you simply test the same path libevent will
use to fetch the time? ÂThe decision to use CLOCK_MONOTONIC vs.
gettimeofday() could be taken first, then a few queries in a row of
the clock via the selected mechanism and some threshold used to decide
whether to cache or not (perhaps with a way to force the choice, in
case). ÂIf the trapping clock reads are 100x slower than the mapped +
TSC approaches, a sane threshold that's reasonably future-proof seems
achievable.
I'm not volunteering to do this, either, I'm afraid.
Cheers,
Dave Hart
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users  Âin the body.