On Tue, Jun 26, 2012 at 8:41 AM, Nick Mathewson <ni...@freehaven.net> wrote: > On Mon, Jun 25, 2012 at 1:20 PM, Zack Weinberg <za...@panix.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
