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