apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_bucket_simple_split
Date Mon, 27 Aug 2001 05:00:33 GMT
From: "Roy T. Fielding" <fielding@ebuilt.com>
Sent: Sunday, August 26, 2001 11:26 PM


> > No.  There really aren't many sendfile implementations that allow you to
> > transmit more than an apr_size_t, if you start digging the man pages.
> > Afraid this was a concensus decision make while you were on holiday.
> 
> Ummm, no it wasn't.  You mentioned it on the mailing list and both Bill
> and I said it wasn't appropriate for a bucket to be limited to apr_size_t
> bytes, and then you committed a huge change to make it all consistent.
> It was better than the previous mishmash, so I saw no reason to veto it,
> but you can't call that a concensus (not even a lazy one).

I can certainly accept that interpretation of events.

> > Since buckets are atomic units,
> > they need to correspond to an atomic sendfile/read/whatever.
> 
> No they aren't.  They are buckets of data -- nothing to do with atomicity.

Then we disagree on that point.

> > The -brigade- is effectively unlimited.  But individual buckets represent one
> > 'apr_size_t' worth of data.  The code became immensely less complex, and
> > since 
> > nobody else worked on buckets type/data safety, I fixed this to be consistent
> > through the server.
> 
> Consistency is good.

There we go agreeing again.

> > > First off, that the point should be an apr_off_t.
> > 
> > -1, and that's a veto, until you (or anyone else) writes a proper patch to
> > handle all apr-util and http buckets paying attention to the size arguments,
> > throughout, and mapping between size and len and off.  Until that happens,
> > this is a size_t.
> 
> Great, so now the implementation works but the interface is wrong.  Guess
> which is harder to fix after a major release?  I think its fine that the
> code has been cleaned up, but the fact is that this interface will change
> back to being apr_off_t at some point.  And if you don't like that, then
> sorry -- I'd rather veto your commit and go back to the inconsistent state
> of warnings on win32 than allow an interface to persist that is just plain
> wrong.

First, I said I would be happy to see the server in a stable state with either 
the apr_size_t or apr_off_t interpretations of a bucket.  I did the work to
interpret it consistently as an apr_size_t.  If someone is motiviated, then
I'd back them, if their API changes make sense.  I tried to do it the other
way (apr_off_t) myself, so I can tell you the end result makes no sense overall.
After fighting it three days, I threw away that patch and started over.

I have yet to see a valid reason for buckets to need apr_off_t.  But let me
offer an alternative.

If we define an 'infinite' bucket, of MAX_SIZE_T length, that you can split
as many times as you want and feed into sendfile, then great.

Oh, wait, sendfile takes an apr_size_t length arg.  Some implementations will
only accept an int's worth.  Even SSL BIO's wont address bigger than an 
apr_size_t.  Carts or horses?

If a bucket represents a networkable/readable/writable part of a conversation,
there is no need for apr_off_t chunks of content.  But if you like, we can go
the extra mile and support bigger 'file' buckets, with their own file_length,
their own semantics on bucket_make_file(), etc.  The bucket brigade code can
just treat it as an unknown size bucket (if it asks, it will be told, this
is huge, don't ask.)  And you can split it, over and over again.

Just an extra option.

Bill







Mime
View raw message