apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: svn commit: r1783755 - /httpd/httpd/trunk/server/mpm/event/event.c
Date Mon, 20 Feb 2017 15:06:48 GMT
On 20.02.2017 15:55, Jim Jagielski wrote:
>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eissing@greenbytes.de>
wrote:
>>
>>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski <jim@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

Mime
View raw message