> Am 20.02.2017 um 17:22 schrieb Jim Jagielski <j...@jagunet.com>: > > >> On Feb 20, 2017, at 10:58 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> >> So as Brane says, if one sets a mutex to the allocator of a pool >> because (s)he wants pool_create/destroy() to be thread-safe, it does >> not necessarily wants the same for palloc() and friends (e.g. the pool >> is used by a single thread). >> > > OK, I get that... I can see that understanding of pool allocation. > >> I think we should not (re)use the allocator mutex if we want the pool >> allocations to be thread-safe, but precisely have a separate pool >> mutex. > > That also makes sense... My thoughts were that people were NOT > using the allocator mutex specifically because it did NOT do want > they wanted or needed and that leveraging the allocator mutex to > be applied during all real allocations of memory, even local node. > > I still tend to think that it being located in the allocator > makes the most sense, or, at least, a flag that the mutex > should be "global" or not... That is, someone uses apr_allocator_mutex_set() > to set the mutex and something like apr_allocator_mutex_coverage_set() to > provide the finer control over which cases the mutex needs to be used.
It could be done, but who would use it that way? The thread safety of pools does not make something like mod_http2 safe by itself. It will not solve the problems of destruction sequences across threads, nor the problems of double frees or uses after free. I think the current design has remedied those problems successfully (fingers crossed) and correct pool use per thread is trivial in comparison. I am not against adding such a feature. I'm only saying that I do not ask for it... ;-) -Stefan
