Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3CBB17EA.2060303@cnet.com>
Date: Mon, 15 Apr 2002 11:11:54 -0700
From: Brian Pane <brian.pane@cnet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.9) Gecko/20020311
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: [PATCH] Re: the most common seg fault on daedalus
References: 
 <Pine.LNX.4.44.0204151318390.9847-100000@deepthought.cs.virginia.edu>
 <m3y9fohmbw.fsf@rdu88-250-035.nc.rr.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff Trawick wrote:

>Cliff Woolley <jwoolley@virginia.edu> writes:
>
>>On 15 Apr 2002, Jeff Trawick wrote:
>>
>>>What happens if we kill the cleanup on the apr_mmap_t when we create
>>>an mmap bucket?
>>>
>>That would work [and would be the preferable solution as far as I'm
>>concerned], but there's currently no API to do it with.  To kill the
>>cleanup, you need access to the cleanup function itself, but it's static
>>to apr/mmap/*/mmap.c.
>>
>
>I know; I didn't want to clutter the attempt to find the right
>solution with such details :)
>
>I'm having a hard time thinking of a reasonable way to expose enough
>information so that the cleanup can be killed.  Some ugly helper
>function could be exported by APR.  Or maybe force the address of the
>cleanup function to be stored at offset 4 of the apr_mmap_t :)
>
>(I actually prefer the latter...  It buys us time until the
>hypothetical point where there are similar cleanup ordering problems
>with other parts of APR and we have to come up with a solution that
>solves today's problem and some new problem.)
>

I like Justin's suggestion: a generic function that removes all cleanups
registered for a given object.

In fact, we could even do this by overloading apr_pool_cleanup_kill() to
allow NULL as the cleanup pointer, where NULL means "unregister all cleanups
that match this object."

--Brian