apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1783755 - /httpd/httpd/trunk/server/mpm/event/event.c
Date Mon, 20 Feb 2017 14:48:59 GMT
[Oups, meant to reach the list(s)].

On Mon, Feb 20, 2017 at 3:46 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 3:16 PM, Jim Jagielski <jim@jagunet.com> wrote:
>> 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?
>
> That could be useful, but at a cost for every allocation (not only
> when the active node is exhausted).
>
> And we don't need it for http/1 requests processing for example for
> now, while it may be interesting for ptrans for requests to easily
> allocate there (not anyhow of course...).
>
> So I'd rather use another mutex for synchronized allocations
> (when/where needed by the user) with an explicit setting (at creation
> time) like apr_pool_set_sync_alloc(), and then a per-call
> apr_palloc_sync() maybe?

Mime
View raw message