On Fri, 2 Mar 2001, Elrond wrote:
>
> I've some further notes about pools.
>
> The reason, why I asked for refcounting:
>
> An object might want to live in two pools.
under the current impl. of apr_pool.c, it may be possible to modify it to
do that.
but it's currently not set up like that and
I've some further notes about pools.
The reason, why I asked for refcounting:
An object might want to live in two pools. Of course it
should only die, if both pools do not anymore reference
that object.
Of course, the object can do the refcounting itself,
pointing the pools destroy-fn-ptr to its
> > i'm going over to sander's at the w/e, we'll see if we can thrash it out.
>
> Please let us know your result. We've talked about types of pools before.
> One that keeps the current semantics, one that maps straight to malloc/free,
> and one that handled shared memory.
>
> I didn't know about
On Fri, Mar 02, 2001 at 09:03:59PM +1100, Luke Kenneth Casson Leighton wrote:
>...
> in xmlvl, i investigated splitting out the pool code into stackable pools.
> sander and i came up with sma_mem_sys as a result.
>
> imagine that you want to do secure memory stacking, using the gpg
> memory-lockin
On Fri, 2 Mar 2001, Greg Stein wrote:
> Getting long here. Watch out! :-)
split in two :)
> Even the connection pool is a child of another. The pools can be described
> as a tree of pools, with a single global pool created at startup.
greg,
in xmlvl, i investigated splitting out the pool code
