Re: [Libevent-users] silly question: 1.x to 2.x event_add behavior

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Apr 30, 2014 at 9:28 AM, Denis Hainsworth
<denis@xxxxxxxxxxxxxxxxxxx> 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
>> <denis@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.