Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (herse.apache.org: local policy)
Date: Fri, 29 Dec 2006 09:44:35 -0800
From: Chris Darroch <chrisd@pearsoncmg.com>
Subject: Re: reslists and sub-pools
In-reply-to: <4592F209.1060005@pearsoncmg.com>
To: dev@apr.apache.org
Message-id: <45955403.1000403@pearsoncmg.com>
Organization: Pearson CTG/CMG
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <458C73D7.4060609@pearsoncmg.com> <458CDED3.8000108@apache.org>
 <4592F209.1060005@pearsoncmg.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060423

Hi --

Chris Darroch wrote:

>    Yes, thank you, that would work nicely!  If apr_reslist_create()
> registered its cleanup function as a pre-cleanup, I think it would
> work just as you say; existing users of reslists who might have
> apr_pool_destroy() in their destructors wouldn't need to alter
> anything.  I guess this fix would require a joint release of
> APR and APR-util ... how does that work, BTW?

   I suppose the most obvious thing might be to have APR export
an APR_HAS_PRE_CLEANUP, then add a simple conditional in
apr_reslist_create() to use a pre-cleanup if that's available.

   Alternately, APR-util's autoconf could test for the existence
of apr_pool_pre_cleanup_register() and set an APU_HAS_PRE_CLEANUP,
I guess.  Out of interest, which would be the preferred option?

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B