From cvs-return-1488-apmail-apr-cvs-archive=apr.apache.org@apr.apache.org Tue Jun 26 15:42:46 2001 Return-Path: Delivered-To: apmail-apr-cvs-archive@apr.apache.org Received: (qmail 30407 invoked by uid 500); 26 Jun 2001 15:42:37 -0000 Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: dev@apr.apache.org Delivered-To: mailing list cvs@apr.apache.org Received: (qmail 30340 invoked by uid 500); 26 Jun 2001 15:42:32 -0000 Delivered-To: apmail-apr-util-cvs@apache.org X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Tue, 26 Jun 2001 11:42:30 -0400 (EDT) From: Cliff Woolley X-X-Sender: To: cc: Subject: Re: cvs commit: apr-util/buckets apr_buckets_mmap.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Tue, 26 Jun 2001 rbb@covalent.net wrote: > Your right, this can do that. However, we really can't keep that from > happening. In reality, the mmap_setaside function should just map it back > to a file opened out of the new pool. Hmmm... why's that? Once the file is MMAPed, you don't even need the original file to be open anymore (you don't have a reference to it anyhow). The OS's MMAP doesn't know anything about pools, so all we have to do is transfer the apr_mmap_t structure itself over to a new pool and we're done. What am I missing? --Cliff -------------------------------------------------------------- Cliff Woolley cliffwoolley@yahoo.com Charlottesville, VA