> Am 20.02.2017 um 16:08 schrieb Jim Jagielski <j...@jagunet.com>: > > Again, this would ONLY happen if the underlying allocator has > a mutex!
But isn't that now true for all conn_rec->pool and thus r->pool and c->bucket_alloc etc? > >> On Feb 20, 2017, at 10:06 AM, Branko Čibej <br...@apache.org> wrote: >> >> On 20.02.2017 15:55, Jim Jagielski wrote: >>>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> >>>> wrote: >>>> >>>>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski <j...@jagunet.com>: >>>>> >>>>> The below got me thinking... >>>>> >>>>> Right now, the pool allocator mutex is only used when, well, >>>>> allocator_alloc() is called, which means that sometimes >>>>> apr_palloc(), for example, can be thread-safeish and sometimes >>>>> not, depending on whether or not the active node has enough >>>>> space. >>>>> >>>>> For 1.6 and later, it might be nice to actually protect the >>>>> adjustment of the active node, et.al. to, if a mutex is present, >>>>> always be thread-safe... that is, always when we "alloc" memory, >>>>> even when/if we do/don't called allocator_alloc(). >>>>> >>>>> Thoughts? >>>> So, apr_p*alloc() calls would be thread-safe if a mutex is set in >>>> the underlying allocator? Hmm, at what cost? would be my question. >>>> >>> The cost would be the time spent on a lock on each call to apr_palloc() >>> or anything that *uses* apr_palloc(). >>> >>> The idea being that if the underlying allocator has a mutex, the >>> assumption should be that the pool using that allocator "wants" >>> or "expects" to be thread-safe... It seems an easy way to create >>> thread-safe APR pools, but I could be missing something crucial >>> here. >>> >>> Of course, if the allocator does NOT have a mutex, no change and >>> no cost. >> >> >> I've always understood that creating subpools is thread safe iff the >> allocator has a mutex, but allocating from any single pool is not, by >> definition. Acquiring a mutex for every apr_palloc() seems like a good >> way to throw away pools' speed advantage compared to malloc(). >> >> -- Brane > Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
