Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 9 May 2001 18:48:42 -0700 (PDT)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: Luke Kenneth Casson Leighton <lkcl@samba-tng.org>
cc: <new-httpd@apache.org>, Ben Laurie <ben@algroup.co.uk>,
    Ryan Bloom <rbb@covalent.net>,  <dev@apr.apache.org>
Subject: Re: APR shared memory requirements.
In-Reply-To: <20010509215150.A19692@angua.rince.de>
Message-ID: <Pine.LNX.4.33.0105091822320.12142-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:

> my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> problem???

nope -- the ap_pool_join() is a promise by the caller that they won't
destroy pool B prior to destroying pool A.  well, if you think of this in
terms of 1.3, which never shares pooled data between threads, what i'm
really saying is that none of the structures (such as tables) which have
data allocated in both pools A and B won't be accessed after B has been
destroyed.

typically B is a sub-pool of A even in these cases, but sub-pools can
theoretically be freed before the parent -- and if you have a table
allocated in A which has pointers to data in B then this results in memory
corruption.

so the debugging code is there to test that when you do this A/B thing
that you either get a warning, or the code in question needs to make the
"ap_pool_join promise".

if you look at the ap_pool_join code you'll see that the side-effect it
has only modifies data which is present when POOL_DEBUG is active.

> uhh, they may be hierarchical, however they all allocate from the
> same memory, using a static 'management' list.  the 'management' memory
> for pools most definitely is _not_ hierarchical.

the block list you mean?  yeah, no hierarchy there.  (and it's strictly
not required by the pool API, it's a behind-the-scenes optimisation.)

> ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
> [a la apr_memsys: stackable memory system we're putting together].

in OO lingo you mean inheritance right?

> therein lies my difficulty with this.  if you consider doing
> 'stackable' memory systems, where you have two pools that
> allocate from two totally different memory systems, they can _not_
> be apr_pool_join()ed, end of story.

why not?

you can still promise that you won't free pool B before you're done using
cross-pool structures.  ap_pool_join() is a statement about the lifetime
of those two pools (and this is what my comments in the code try to
explain).

of course it's pretty hard to make this promise if one of the pools has
global lifetime, and is accessed by multiple threads.  this is possible in
2.0 now isn't it?  i think that's a mistake if so :)  amongst the many
features of 1.3 pools were that they were single-threaded access, zero
mutexes required on the fast path.

but if one of the pools has a global lifetime, and the other doesn't, then
you shouldn't be making the ap_pool_join() promise, and so there's no
problem with the function.

if you want to continue to support POOL_DEBUG (i am really so far out of
date with 2.0 internals now that i can't make a judgement on how useful it
is), then i suspect what you need to do is provide a private function
which, when given a void *, returns what pool it belongs to.  this would
be implemented by all the pool classes.

that handles the POOL_DEBUG stuff which is in the union block_hdr
structure.

the "joined" stuff shouldn't need to change, it should be same for all
pool implementations.

note:  i personally think that pools made sense in an http server for
a few things (the fast path through static responses, and that's about
it), but don't make any sense at all in pretty much every other program
in existence, and i kind of question the abuses they're going through.

-dean