On 20.02.2017 16:08, Jim Jagielski wrote: > Again, this would ONLY happen if the underlying allocator has > a mutex!
Sure, but you need an allocator with a mutex in order to safely create pools in a multi-threaded environment. For all practical purposes this means that the allocator must be thread-safe #ifdef APR_HAS_THREADS. Now in certain cases you may have enough control of the structure of the application that you're able to make a more fine-grained decision about whether your allocator must be thread-safe or not. But libraries, such as Subversion for example, do not have that luxury. APR pools were designed with the assumption that separate threads will always use separate pools whenever concurrent allocations are possible. This assumption happens to fit pretty well with the server/worker/thread-pool architecture that APR was designed to be used in, and is not an inordinate burden for other architectures. Your proposed change would drastically slow down existing code or force it to use non-thread-safe allocators and invent and retrofit explicit locking around subpool creation. Whilst the change is, strictly speaking, backward compatible, I can imagine people being slightly miffed off if their apps drastically slow down because they happen to be linked with a new version of APR. -- Brane >> 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
