httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: svn commit: r1783755 - /httpd/httpd/trunk/server/mpm/event/event.c
Date Tue, 21 Feb 2017 14:12:15 GMT

> Am 21.02.2017 um 14:54 schrieb Yann Ylavic <>:
> 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

View raw message