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