I was thinking about an easier change, which is to add another timer update before timeout_correct(base, &tv). This is the function that could be using an out-of-date timestamp, if event_process_active(base) takes longer than expected.
But sorry I really couldn't find any bandwidth to verify whether the change will work or not. -Haiping On 4/23/09 9:06 AM, "Nick Mathewson" <ni...@freehaven.net> wrote: On Tue, Apr 14, 2009 at 11:23:24PM -0700, Haiping Zhao wrote: [...] > Anyways, I'll have to re-think our model. At the same time, may I > ask why the change? Was that for calling gettimeofday() less number > of times to be more efficient? But the code only updates > base->tv_cache once per loop, each of which may take several > milliseconds to finish. Doesn't that leave huge space for an > inaccurate timestamp? Adrian is right that the call can be expensive on some platforms. But you're right that sometimes timing accuracy matters more than performance. This would seem to be a great candidate for an event base configuration flag in the 2.0.x series: there could be a new flag in the event_base_config_flags enumeration to disable the timeval cache. Anybody want to code it up? yrs, -- Nick
_______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
