On 06 Oct 2015, at 7:29 PM, Graham Leggett <[email protected]> wrote: > I am wondering if the EOR bucket is a suboptimal way to clean up after > ourselves. > > The MPM itself is in a position to know when the filter buffers are all empty > and it is safe to delete a request pool. I am imagining a “shutdown set”, > which contains the pools which have been marked as ready to shut down. If > there is a pool in the shutdown set, walk the outstanding filters and look > for any filters whose pools are descendants of that pool, and check if the > filters are empty. If so, apr_pool_destroy() and we’re done. If the “shutdown > set” is empty, do nothing. > > Instead of creating an EOR bucket, we call an MPM API that says “add this > pool to the shutdown set”, and then forget about it. > > Legacy MPMs fall back to EOR behaviour, but we deprecate it. > > I think the above is a far safer approach than assuming filters will “do the > right thing”.
Having done some further digging that isn’t that workable. While the presence of a filter with setaside data in it tells us definitely that we shouldn’t destroy the brigade yet, it is very difficult to determine when we should. I think we’ll need to compromise and provide an async switch that in v2.4 defaults to “connection” (restrict async behaviour to connection filters only), and can be optionally set to “request” (async behaviour for connection and request filters) if the filters in use allow it. Regards, Graham —
