From dev-return-2561-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sat Jun 09 01:42:43 2001
Return-Path:
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 77083 invoked by uid 500); 9 Jun 2001 01:42:39 -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 77067 invoked from network); 9 Jun 2001 01:42:37 -0000
X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs
Date: Fri, 8 Jun 2001 21:42:42 -0400 (EDT)
From: Cliff Woolley
X-X-Sender:
To: "Roy T. Fielding"
cc:
Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
In-Reply-To: <20010608154009.E965@waka.ebuilt.net>
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 Fri, 8 Jun 2001, Roy T. Fielding wrote:
> Seriously, though, there is no reason for the setaside function to need
> a full memory allocation system (pool) passed just to do a bit of byte
> stuffing within a buffer.
It's not just a "bit of byte stuffing within a buffer" at all. The pool
has some lifetime associated with it. The reason for passing in a pool is
to be able to say to the buckets code "this resource should live at least
THIS long". That also implies that some data structures (not data!) will
need to be copied into that pool, ie an apr_file_t or an apr_mmap_t. It
would only work to just pass an arbitrary storage pointer if we actually
copied all of the data represented by the bucket into that buffer, and
that's not the idea at all.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA