> Am 21.02.2017 um 14:54 schrieb Yann Ylavic <ylavic....@gmail.com>: > > We seem to be talking past each other, I'll _try_ to synchronize ourselves :)
We'll get there! :) > On Tue, Feb 21, 2017 at 1:57 PM, Stefan Eissing wrote: >> >> You have me confused now. If you did that all only for h2, then, I >> think, we can live without them all nowadays, because: > > Actually I made the MPMs change mostly for correctness with regard to > any possible module. > > But since it is useless for http/1 and may hurt common performances, I think > I'll revert the changes on the MPMs sides (provided mplx->pool is kept > mutexed!). That is totally fine with me. Please revert that and I make the necessary changes to h2 and run my stress tests, make a v1.9.1 and let others verify this. >> 1. master conn_rec->pool (own allocator, all ops in one thread) >> * h2_session->pool >> - h2_stream->pool >> - h2_mplx->pool >> >> 2. h2_mplx->pool (own allocator, all ops guarded h2_mplx->lock mutex): >> * h2_slave->pool > > OK, so for the crashes you reported yesterday, both MPM's ptrans (aka > master->pool) and mplx->pool were without a mutex. This is what you > tested right? > If so, this is "expected" to crash (at least understood now, sf > pointed us to this in another thread), because nothing is protecting > concurrent creation/destruction of mplx->pool's subpools. I think at this stage, let's get all changes/reverts into trunk. When that is all done, we can talk about changes that I "expect" to work additionally. > [...] >> >> This is how it is intended to be used. > > Got it (I think :) :) > It should be both safe an performant, could you pass your stress tests on it? > That is, with current trunk, comment out the apr_allocator_mutex_set() > used in mpm_event's listener_thread() and h2_slave_create(). > > Unless I (again) misunderstood what you tried to tell me :) Will do, once you revert. > > Thanks! > Yann. Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
