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

[Denis Hainsworth <denis@xxxxxxxxxxxxxxxxxxx>]

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.

If we know that then we can focus our efforts on which behavior seems
broken or if this is a known change that the folks that upgraded
libevent missed.

-denis
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.