Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 54776 invoked by uid 500); 26 Jun 2001 14:10:44 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 54587 invoked from network); 26 Jun 2001 14:10:35 -0000 X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Tue, 26 Jun 2001 10:10:30 -0400 (EDT) From: Cliff Woolley X-X-Sender: To: Greg Stein cc: , Subject: Re: file_setaside() In-Reply-To: <20010626021540.H1908@lyra.org> 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, Greg Stein wrote: > The setaside() could be called on *really* large files. Calling mmap could > be a very bad thing. Just dup the FILE bucket and leave it at that. The > decision to do the mmap can/should come when it becomes necessary. Okay, I'll change file_setaside() so that it doesn't MMAP the file and mmap_setaside() so that it doesn't copy into a pool. That makes me feel better. > > > Isn't it just a matter of killing the cleanup associated with one pool > > > and registering the cleanup with the new pool? > > I'm with Ryan: dup the bugger. It'd be nice if there was an apr_file_t_dup() [if you catch my drift... I don't know what you'd really call it] that does everything apr_file_dup() does *except* calling dup(). Then I'd have no problem at all with this approach. --Cliff -------------------------------------------------------------- Cliff Woolley cliffwoolley@yahoo.com Charlottesville, VA