Again, this would ONLY happen if the underlying allocator has
a mutex!
> 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
