On Wed, Apr 30, 2014 at 9:28 AM, Denis Hainsworth <de...@alumni.brandeis.edu> wrote: > On Wed, Apr 30, 2014 at 08:44:24AM -0400, Nick Mathewson wrote: >> On Wed, Apr 30, 2014 at 8:24 AM, Denis Hainsworth >> <de...@alumni.brandeis.edu> wrote: >> > I have question I'm hoping will short-cut an investigation I'm doing >> > into some inherited code. Essentially we have some real simple code >> > which sets up an event with a timer and depending on certain things >> > changes the timer during each loop. We are seeing a difference in >> > behavior from when it was using 1.x libevent and 2.x. >> > >> > We call event_set at the start of the code for 60 seconds, and then >> > during each loop use event_add to set the timer to however many seconds >> > from current time to get to the next minute. Its pretty dumb code and >> > there are lots of things wrong with it but it has been working. >> >> I think you might be mixing something up here; event_set() doesn't set >> timeouts; that's in event_add(). >> >> event_add(), on the other hand, doesn't change callbacks. >> >> It's not supported to call event_set() on an event that is currently >> pending, and it wasn't supported in Libevent 1.x either -- most >> programs that do that will get mysterious crashes as the internal data >> structures get corrupted. It's like using free()d memory -- some >> programs will get away with it, and some programs won't, but it's a >> bug either way. >> >> If you need to call event_set() on an event that might be pending, you >> need to call event_del(), then event_set(), then event_add() again. >> That's necessary for correctness with Libevent 1.x and 2.x as well. >> >> My apologies if I haven't understood the situation, though; if you >> could post a tiny code sample demonstrating the behavior you're >> talking about, that would probably help track down the issue. > > Thanks Nick, I was trying to keep the question simple as there are a > number of extra complexities we are dealing with like that there is a > python layer in between libevent and the script. All I need to know > right now is when event_add is called on an existing event to change the > timer (which is a valid thing to do per the documentation) should that > mean the new timeout X is X seconds from when event_add was called or > should it be X seconds from the beginning of the current callback.
The semantics are that it the event should be executed X seconds from when (approximately[*]) when event_add() was called. I believe these were the semantics in Libevent 1 and Libevent 2 both. [*] You should probably also be aware that Libevent 1 and Libevent 2, by default, tried to minimize calls to clock_gettime(); see the gettime() function for more info on that. You can control this behavior in Libevent 2 by using EVENT_BASE_FLAG_NO_CACHE_TIME. You should probably know that there are new semantics for EV_PERSIST events with timeouts in Libevent 2.0; previously, there was no defined meaning to an event timeout on an EV_PERSIST event. In Libevent, it was defined as creating a periodic event. hope this helps, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
