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).
