Return-Path: 
 <dev-return-4832-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 81854 invoked by uid 500); 14 Nov 2001 18:12:54 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 81841 invoked from network); 14 Nov 2001 18:12:53 -0000
Date: Wed, 14 Nov 2001 13:12:43 -0500 (EST)
From: Cliff Woolley <cliffwoolley@yahoo.com>
X-X-Sender: <root@deepthought.cs.virginia.edu>
To: Brian Pane <bpane@pacbell.net>
cc: <dev@apr.apache.org>
Subject: Re: [PATCH] Re: mmap_setaside?
In-Reply-To: <3BF2A267.1080903@pacbell.net>
Message-ID: 
 <Pine.LNX.4.33.0111141305560.13001-100000@deepthought.cs.virginia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Wed, 14 Nov 2001, Brian Pane wrote:

> Actually, the more I think about it, the less I like the idea of
> exposing mmap_cleanup in any form (including the function pointer
> in the struct).  The problem is that it introduces extra coupling
> between the mmap code and the bucket code, so that the latter can
> take advantage of an implementation detail of the former (the fact
> that there happens to be exactly one cleanup function registered
> per apr_mmap_t in its original pool).

I had sort of the same objection, which is why I didn't just go ahead and
do this.  <sigh>

> As an alternate implementation, how about this?
>   apr_status_t apr_pool_cleanup_transfer(apr_pool_t *src, apr_pool_t *dst,
>                                          void *object);

That has problems, too, because it doesn't work right for all types of
objects.  It only happens to work for MMAPs because MMAPs don't have other
stuff allocated from the pool, like internal locks and stuff.  (I believe
this would break horribly if you ran it on an apr_file_t, for example.)

I think the ideal situation would be if we had an apr_mmap_dup() similar
to our apr_file_dup().  apr_file_dup() already solves this problem for
files by ensuring that a duplicate copy of the file descriptor lives as
long as the given pool.  apr_mmap_dup() in the case of duping into an
ancestor pool could do exactly what we're trying to get mmap_setaside() to
do: copy the apr_mmap_t() into the ancestor pool and tweak the cleanups.
In the case of disjoint pools, it could do something else (what I haven't
decided yet).  Then mmap_setaside() becomes as easy as file_setaside() is.

Thoughts?

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA