On Mon, Jul 6, 2009 at 10:56 PM, Mladen Turk<[email protected]> wrote: > Paul Querna wrote: >> >> Can't sleep, so finally writing this email I've been meaning to write >> for about 7 months now :D >> >> Pools don't help, but don't really make it worse, and are good enough >> for the actual cleanup part -- the difficultly lies in knowing *when* >> you can cleanup an object. >> > > Pool pre cleanup is meant to deal with such issues. > You register a pre-cleanup and it will run before any of the > pool objects are actually destroyed. > > In your case pre-cleanup callback could break the wait loop > and make sure you don't reference a zombie object. > The only issue left is guarding thread access to a singleton > pollset interrupt (we even have pollset_interrupt with latest APR) > from a pre-cleanup callback (or simply using a queue to serialize > the objects that needs to get removed from the pollset)
This deals with removing an event from the pollset, but what about an event that had already fired, as I gave in the original example of a timeout event firing the same time a socket close event happened? In that state you have two threads both in a 'run state' for a connection, and I'm not sure how the pre-cleanup to pools solves this in any way? Thanks, Paul
