Jeff Trawick <[EMAIL PROTECTED]> writes:
> On 5/12/05, Joe Schaefer <[EMAIL PROTECTED]> wrote:
>> Without this patch, the new apr_pool_join stuff in apr's trunk
>> segfaults all over the place.
>
> Why? Is worker MPM doing something wrong (creating standalone pool in
> that manner), or does APR need some help?
>
>> Index: server/mpm/worker/worker.c
>
>> apr_allocator_create(&allocator);
>> apr_allocator_max_free_set(allocator, ap_max_mem_free);
>> - apr_pool_create_ex(&ptrans, NULL, NULL, allocator);
>> + apr_pool_create_ex(&ptrans, pconf, NULL, allocator);
>
> Isn't this on the listener thread? Do we need to be mucking with the
> pconf pool on non-main thread? Sounds dangerous (non-thread-safe).
Yes, it's on a listener thread. Looking at apr_pool_create_ex,
it does take a mutex on pconf, so I think it's a thread-safe operation.
All this does is use the pconf pool instead of the global pool:
APR_DECLARE(apr_status_t) apr_pool_create_ex(apr_pool_t **newpool,
apr_pool_t *parent,
apr_abortfunc_t abort_fn,
apr_allocator_t *allocator)
{
apr_pool_t *pool;
apr_memnode_t *node;
*newpool = NULL;
if (!parent)
parent = global_pool;
--
Joe Schaefer
