Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 10 Dec 2009 11:03:27 +0100
Message-Id: <1095842143@web.de>
MIME-Version: 1.0
From: Edgar Frank <ef-lists@email.de>
To: Graham Leggett <minfrin@sharp.fm>
Cc: dev@apr.apache.org
Subject: Re: question about pool-cleanup order
Organization: http://freemail.web.de/
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

Graham Leggett wrote:
> Edgar Frank wrote:
> > But what I've been wondering about is, why subpools are
> > always cleared before the cleanups are run.
>
> Subpools are allowed to reference memory allocated from the
> parent pool.
> What this means is that you have to clean the subpool before
> trying to clean the parent pool, otherwise the subpools might
> end up containing dangling pointers to memory allocated from
> the parent pool.

Hmm, okay so the point is that any subpool can be sure that any
object allocated on the parent pool isn't cleaned by its
cleanup function up yet (actually, it's about the cleanups
themselves and not necessarily memory allocation).

But, referring to your example of a closed httpd connection -
there still wouldn't be a problem if everything is created and
cleaned up in order. The cleanup for the connection_rec would be
still registered before the request-subpool is created, so its
cleanup would be run after it.

Assuming the following example for a pools life:
- cleanup function "c1" registered
- subpool "s1" created and registered
- cleanup function "c2" registered

Now the pool is destroyed/cleaned up. The current behaviour is:
- clean subpool "s1" (and recursively apply the same pattern)
- run cleanup "c2"
- run cleanup "c1"
- free the held memory

While every cleanup on "s1" can rely that every object on the
parent pool is alive and no cleanup is run yet, cleanup "c2"
might refer to data on "s1", as it was registered after the
subpools creation. This doesn't feel natural to me, as it changes
the order in which I created objects.

What would speak against this order?
- run cleanup "c2"
- clean subpool "s1" (and recursively apply the same pattern)
- run cleanup "c1"

The only rule I'd have to follow is, that every object I want to
use in the subpool persistently (in other words: usable during
cleanups) must be created (->have its cleanup registered) before
the subpool itself.

The current approach protects me in subpool cleanups, but opens
problems during parent pool cleanup. E.g. in reslists, if you
subpool in constructors and try to access these pools in the
destructor.

> That said, apr v1.4 offers a apr_pool_pre_cleanup_register()
> function, allowing you to register a cleanup that runs before
> the subpools are cleared. It may do what you want to do.
I saw apr_pool_pre_cleanup_register also in 1.3.9 and considered
using it. But I refrained from doing so, because it mixes up
destruction order even more and makes things extremly hard to
understand.
I'm currently rather thinking about creating unmanaged pools
(just managed by the global pool) and destroy them explicitly
when the time is right.

Please don't get me wrong, this is no offense in any way. I just
want to discuss in a productive way and understand the APR design
decisions better and maybe even contribute to the project by
sharing my thoughts. :-)

Regards,
Edgar
--