apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Sat, 09 Jun 2001 09:04:36 GMT
On Fri, Jun 08, 2001 at 09:42:42PM -0400, Cliff Woolley wrote:
> 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.

Right. We don't want to copy the apr_file_t... we just wnat to ensure that
it sticks around longer.

If a filter wants to keep bytes (rather than buckets), then fine. But for
the things setting aside buckets... we need a way to ensure the thing can
live long enough.


Greg Stein, http://www.lyra.org/

View raw message