Re: [Libevent-users] Callback after all events from the current batch have been cleared

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Mon, Jun 25, 2012 at 1:20 PM, Zack Weinberg <zackw@xxxxxxxxx> wrote:
> I'm looking at a bug which appears to come down to: some of my event
> callbacks deallocate events, bufferevents, and/or their callback data. Under
> difficult-to-reproduce circumstances, libevent appears to queue up calls to
> my callbacks (possibly implicitly via internal control flow), and call them
> even though the associated events and data have been deallocated.  I wish to
> apply a large hammer to this problem: delay deallocations until after all
> queued-up callbacks have been processed, but before libevent asks the OS for
> the next batch of events.
>
> I *think* this can be done with a timer event which is assigned a lower
> priority than all other events in the program, and which is event_add()ed
> with an immediate timeout whenever there are deallocations pending.
>
> Will this work?

It will work only so long as there are no "deferred callbacks" queued.
 In Libevent 2.0, they use a separate queue than all other events.
I'm hoping to change that in 2.1 if anybody gets around to reviewing
the 21_event_callback_v3 branch in my github repository, which should
make "event" and "deferred callback" both special cases of
"event_callback", and thereby make deferred callbacks use the same
priority system as everything else.

> Is there a better way to do this?

Well, the behavior you describe shouldn't actually be happening:
Libevent should not call any callbacks on *foo* after you have called
the appropriate *foo*_del() or *foo*_free() function.

If you can come up with an example of when the undesirable behavior
occurs -- ideally with a minimal test case to reproduce -- we might be
able to track it down.

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