You are confusing pool mutexes with allocator mutexes...
> On Feb 20, 2017, at 10:26 AM, Branko Čibej <br...@apache.org> wrote:
>
> 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
>
>
