[apologies to NormW - just accidentally sent a reply to him and not the list]
On 28 Jul 2011, at 02:24, NormW wrote:
> Hi,
> Raised this some months ago but response was left than deafening, and
> advice says 'have another go', so...
Netware being a minority platform, few are qualified to comment.
> In apr\memory\unix\apr_pools.c:
>
>> APR_DECLARE(apr_pool_t *) apr_pool_parent_get(apr_pool_t *pool)
>> {
>> #ifdef NETWARE
>> /* On NetWare, don't return the global_pool, return the application pool
>> as the top most pool */
>> if (pool->parent == global_pool)
>> return pool;
>> else
>> #endif
>> return pool->parent;
>> }
Can you throw any light on the reason for that? I wonder if the semantics
of "parent pool" are messed up?
> in apr\dbd\apr_dbd.c:
>
>> for (parent = pool; parent; parent = apr_pool_parent_get(pool))
>> pool = parent;
>
> Cannot see how NetWare can escape this loop if apr_pool_parent_get()
> returns the same pool passed in to the function.
Indeedie!
> Either (in NetWare case):
>
> - apr_pool_parent_get() has to return something other than the same
> 'pool' to allow the loop to exit, OR
>
> - the loop needs to determine if it got the same pool back (at least in
> NetWare case) and exit the loop.
>
> Comments please.
My first thought was a variant on that: turn the "parent [!= NULL]" test
into a macro that resolves to something different on Netware.
But I wouldn't try without at least a basic insight into those pool semantics.
Did you offer a patch?
--
Nick Kew
