apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: pool stacking
Date Fri, 02 Mar 2001 11:23:33 GMT
> > 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 a GPG memory type :-) Sounds way cool, and I definitely
> bet that we could use that within Apache.

well, it's not so much a GPG memory type as that they have their own
wrappers on memory allocation to make sure that it gets locked (i forget
the system call to do it) and stays in-memory and never swapped to disk.

you don't want your unencrypted private key in a swap file, do you? :)

> We have had some problems with the pool types, however. Consider that you
> pass a function a malloc-based pool. Who calls the free?

ah ha :)

we worked this out.

the sma_mem_sys has pointers to free, destroy, reset, and alloc (which
have corresponding functions - except for free - in apr_pool-ing)

the _users_ of an sma_mem_sys (apache pools, for example), must check if
the parent-sma_mem_sys has either a free or a destroy, and call them if
they exist.

> The function
> doesn't know whether it is a standard pool, or a malloc pool. And inserting
> a bunch of apr_pool_free(ptr) calls (which are noops for some pools) defeats
> the purpose of using pools to avoid carefully tracking free().

...  you still have to call free() in the existing apr_pool code, right???
:) :)

so you call pool->sma_parent->free() instead().

well, actually - implementation of apr_pool_destroy() something like this:

foreach pool alloc'd block:
	if (pool->sma_parent->free != NULL)

followed up by:
if (pool->sma_parent->free_all != NULL)

in this way, you cover _both_ cases where the sma_parent instance can
either be capable of doing freeing _or_ is in fact _yet_ another "pool"
allocation system and doesn't have a free at all.

then, you can have an sma_parent which is in fact another apr_pool.

uhm... a little tricky, i know.

> For shared memory, I think we were having some issues with grabbing the
> right amounts of shared memory, then doing the suballocations. I think this
> can be solved, though.

*scared* :)

 ----- Luke Kenneth Casson Leighton <lkcl@samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."

View raw message