Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <487F1E0A.2040102@apache.org>
Date: Thu, 17 Jul 2008 12:25:14 +0200
From: Mladen Turk <mturk@apache.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20071129)
MIME-Version: 1.0
To: Bojan Smojver <bojan@rexursive.com>
CC: dev@apr.apache.org
Subject: Re: svn commit: r677505 - /apr/apr-util/trunk/misc/apr_reslist.c
References: <20080717054557.AA2E02388A45@eris.apache.org>
 <20080717195057.213327svh8rbt1xc@www.rexursive.com>
In-Reply-To: <20080717195057.213327svh8rbt1xc@www.rexursive.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bojan Smojver wrote:
 > Quoting mturk@apache.org:
 >
 >> Use apr_pool_pre_cleanup_register for reslist cleanup
 >
 > After thinking about this a bit more, this patch may introduce a
 > somewhat unusual (possibly even dangerous) behaviour, as it changes the
 > way cleanups normally work with APR pools.
 >

It only forces calling resource destructors before
its subpools are destroyed.
The operation is exactly the same as if one would explicitly
call destructors for each resource before calling pool_destroy.
So the pool P is not destroyed before its subpools, only
the callback is called before subpools are destroyed.

The standard cleanup on pool_clear(destroy) first destroys
all subpools and then call register cleanups.
This forces (just look at mod_proxy connection pool code)
the user to make some tricks so it can figure out weather
the destructor was called by invalidate or by pool destroy.
If it was by pool destroy then it must skip any subpool
destroy calls, because those would cause core.


Regards
--
^TM