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 <rpl...@apache.org>: > > > > 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 :-) > > > Regards > > Rüdiger Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
