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

[Zack Weinberg <zackw@xxxxxxxxx>]

On Tue, Jun 26, 2012 at 8:41 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> On Mon, Jun 25, 2012 at 1:20 PM, Zack Weinberg <zackw@xxxxxxxxx> wrote:
>> 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.

By "deferred callbacks" do you mean the implementation of
BEV_OPT_DEFER_CALLBACKS, or something else?  This program doesn't use
that, although maybe it should (I'm not at all clear on what that's
supposed to be for).

> 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.

Unfortunately it only happens intermittently, under conditions of
extreme packet loss.  I'd like to improve my test harness to let me
produce such conditions in the lab, as it were, but I've got
inconvenient deadlines...

By code inspection, in 2.0 (didn't check 2.1), I can see a way for it
to happen if BEV_OPT_DEFER_CALLBACKS *is* used: both variants of
bufferevent_run_deferred_callbacks potentially call several callbacks
on the same bufferevent without checking in between to see if one of
the callbacks has deallocated the bufferevent.  (You've got some sort
of reference count in there, so that may be safe as far as the 'struct
bufferevent' itself, but there is no such protection for the callback
data.)

Maybe there is a similar control flow issue in the non-DEFER_CALLBACKS
case but if so it is not obvious to me.  (I *thought* I remembered
seeing a way for the socket bufferevent_readcb to call both the read
and the event callbacks, in the same fashion, but it looks like I
misread it.)

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