apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr_bucket_split : should it take a offset or a size?
Date Mon, 13 Aug 2001 10:39:54 GMT
On Thu, Aug 09, 2001 at 05:05:26PM -0700, Ryan Bloom wrote:
> On Thursday 09 August 2001 15:33, Greg Stein wrote:
> > On Wed, Aug 08, 2001 at 01:40:33AM -0400, Cliff Woolley wrote:
>...
> > > As of late, the rule has become this: individual buckets can contain no
> > > more than an apr_size_t.  A brigade can have total length up to an
> > > apr_off_t.  So apr_bucket_split() and friends SHOULD take an apr_size_t,
> > > because that's the biggest the bucket can be anyway.  Something within
> > > ap_http_filter needs to handle the conversion, I'd expect.
> >
> > FILE, PIPE, and SOCKET buckets can easily be more than "memory-sized".
> > Thus, all of the split and partition functions should take an apr_off_t.
> >
> > When you read, you'll only get back a portion.
> >
> > So... the "rule" you state ought to be changed. It just doesn't apply to
> > certain types of buckets.
> 
> Buckets are buckets.  To have different rules for some buckets than others means that
the 
> API's would be inconsistant.  Plus, PIPE and SOCKET buckets always have a -1 length.
> FILE buckets are basically capped at apr_size_t, because having more than that in one
> bucket doesn't really help you anyway.  The argument was that every operating system
with
> sendfile we support will do a partial write of the file, because 2Gig is too big to send
at one time.
> Without this change, we get all sorts of warnings on platforms where apr_size_t and apr_off_t
> aren't the same.

What?! I'm not saying *some* bucket use one size, and the other buckets
another size. I'm saying all the split functions should be an apr_off_t.

Their content can be larger than apr_size_t, so the split points needs to be
an apr_off_t.

Cheers,
-g

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

Mime
View raw message