[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: bug in apr_brigade.c
From:       "William A. Rowe, Jr." <wrowe () covalent ! net>
Date:       2002-01-24 15:06:26
[Download RAW message or body]

From: "Bill Stoddard" <bill@wstoddard.com>
Sent: Thursday, January 24, 2002 9:00 AM


> > From: "Greg Stein" <gstein@lyra.org>
> > Sent: Thursday, January 24, 2002 3:30 AM
> >
> > > On Wed, Jan 23, 2002 at 12:07:33PM -0600, William A. Rowe, Jr. wrote:
> > >
> > > > 'bucket' is a unit that _may_ be read into memory (although it need not)
> > > > while the 'brigade' may obviously be huge.
> > >
> > > No. A bucket is a unit of data. Totally unrelated to reading into memory.
> > >
> > > It is *entirely* feasible to create a bucket that represents 20G of data and
> > > then shove that out a socket.
> >
> > Yes, it is feasable.  Is it practical?
> 
> Well, yea! Consider a pipe bucket. The pipe is a data source and the network is a data
> sink. We already have code in Apache 2.0 to read from a pipe and dump bytes to the
> network.

and memory is a data sink as well, which is what the API was coded around.
But pipe buckets don't enter the discussion, so much, because they are
length -1.  But just try and send 5GB from a pipe with the content-length
filter inserted :)

Look, anyone who wants to rescope this, feel free to submit a patch.  I'll
veto only as long as it is faulty or doesn't build clean.  That's build clean
where sizeof(apr_off_t) > sizeof(apr_size_t).  If someone creates a patch, 
which doesn't cast around the problems without looking first, I won't stop 
at not vetoing, but I'll even vote for it [in principal.]

Here's betting I don't see a reasonable patch anytime soon.

Bill



[prev in list] [next in list] [prev in thread] [next in thread]