> On Oct 6, 2015, at 1:29 PM, Graham Leggett <minf...@sharp.fm> wrote: > > On 06 Oct 2015, at 7:00 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > >> Yet another filter which does not remove itself after the EOS, and >> destroys the EOR bucket while still using *r after. > > 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”. >
Basic idea seems sound... +1
