httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: mod_http2 and Frequent wake-ups for mpm_event
Date Mon, 06 Feb 2017 13:31:41 GMT
Currently running some tests. Have crashes on the original patch in my test suite. Fixed one,
hunting for the next...

> Am 06.02.2017 um 14:23 schrieb Ruediger Pluem <rpluem@apache.org>:
> 
> 
> 
> On 02/06/2017 01:51 PM, Yann Ylavic wrote:
>> On Mon, Feb 6, 2017 at 1:42 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>> On Mon, Feb 6, 2017 at 1:29 PM, Ruediger Pluem <rpluem@apache.org> wrote:
>>>> 
>>>> 
>>>> On 02/06/2017 11:56 AM, Yann Ylavic wrote:
>>>>> Hi Stefan,
>>>>> 
>>>>> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
>>>>> <s.priebe@profihost.ag> wrote:
>>>>>> 
>>>>>> your last patch results in multiple crashes every second:
>>>>> 
>>>>> Sorry about that, the changes in mpm_event were incorrect (the mutex
>>>>> was cleared with the pool when recycled, hence its pointer was
>>>>> dangling).
>>>>> 
>>>>> New patch attached, this time tested with the httpd framework (where
>>>>> the previous patch segfaulted too).
>>>>> 
>>>>> Thanks,
>>>>> Yann.
>>>>> 
>>>> 
>>>> Hmm, does it make sense performance wise to create the mutex over and over
again?
>>>> Or is this planned to be improved once it is known to fix the crash issue?
>>> 
>>> Yes, I'm thinking of it, but it's not easy because we need a pool to
>>> create the mutex.
>>> Using ptrans makes it cleared on recycle (hence re-created), and using
>>> the parent pool (pconf) requires synchronization.
>>> 
>>> Possibly we could recycle both the pool (or the allocator) and its
>>> mutex, but ap_push/pop_pool() wouldn't be lockless anymore...
>> 
>> Not sure it's really worth it either because apr_thread_mutex_create()
>> should boil down to "*mutex = PTHREAD_MUTEXT_INIT" on *nix, and
>> probably something equivalent for InitializeCriticalSection() on
>> windows...
>> We probably not spend many cycles here (compared to more synchronization).
> 
> The question how much cycles this spends in GLIBC / kernel. I don't know. So maybe its
not worth
> the effort. But if its not worth the effort it is worth documenting why :-)
> 
> 
> Regards
> 
> Rüdiger

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de


Mime
View raw message