apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: cvs commit: apr/memory/unix apr_pools.c
Date Tue, 09 Dec 2003 18:01:54 GMT
On Tue, 2003-12-09 at 18:43, bnicholes@apache.org wrote:
> bnicholes    2003/12/09 09:43:01
> 
>   Modified:    memory/unix apr_pools.c
>   Log:
>   Since all NetWare memory is shared, allowing an application access to the APR global
pool allows it to allocate memory and set cleanups that will never happen even if the application
terminates.
>   
>   Revision  Changes    Path
>   1.203     +7 -0      apr/memory/unix/apr_pools.c
>   
>   Index: apr_pools.c
>   ===================================================================
>   RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
>   retrieving revision 1.202
>   retrieving revision 1.203
>   diff -u -r1.202 -r1.203
>   --- apr_pools.c	6 Nov 2003 00:43:32 -0000	1.202
>   +++ apr_pools.c	9 Dec 2003 17:43:01 -0000	1.203
>   @@ -1792,6 +1792,13 @@
>    
>    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 NULL;
>   +    else
>   +#endif
>        return pool->parent;
>    }

I'm wondering if we shouldn't always decline to return the global pool.
No user should be messing with the apr global pool anyway.

Thoughts?

Sander

Mime
View raw message