On 02/06/2017 01:51 PM, Yann Ylavic wrote:
> On Mon, Feb 6, 2017 at 1:42 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> On Mon, Feb 6, 2017 at 1:29 PM, Ruediger Pluem <rpl...@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.pri...@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 :-)



Reply via email to