apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r1783755 - /httpd/httpd/trunk/server/mpm/event/event.c
Date Mon, 20 Feb 2017 14:55:55 GMT

> 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.


Mime
View raw message