Again, I am only talking about those in which the allocator has a pool... The allocator. Via apr_allocator_mutex_set().
> 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 > >
