apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Netware apr_pool_parent_get
Date Fri, 12 May 2006 19:07:33 GMT
    >>> On 5/12/2006 at 3:25 AM, in message
<20060512092529.GA14658@redhat.com>, Joe
Orton <jorton@redhat.com> wrote:
> /* On NetWare, don't return the global_pool, return the application
>        as the top most pool */
>     if (pool->parent == global_pool)
>         return NULL;
> ...which doesn't do what it is supposed to do, and doesn't do even
> the comment says.  Why does Netware need different semantics for this

> function, what's wrong with exposing the global pool?
> jo

Because the NetWare memory address space is one big memory space that
all running NLMs share.  There are no process boundaries within NetWare
and any running NLM could access memory owned by any other running NLM. 
Therefore if multiple applications are running on top of a shared
APRLib, the global_pool pointer is the pool pointer to all APR allocated
memory no matter which application actually caused it to be allocated. 
So the NetWare APRLib has to emulate a process or application boundary
with APRLib itself.  Something that would normally be taken care of by
the operating system.  That memory boundary is established in the
NetWare APR by allocating an application specific memory pool (pseudo
global_pool) out of the APR global_pool and then making sure that the
application remains at all time within its own allocated application
memory pool.  This code is simply not allowing an APR application to
walk the memory pool hierarchy all the way back to the global_pool since
the global_pool is truely global to all NLMs running on APR.


View raw message