apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: apr_bucket_simple_split
Date Mon, 27 Aug 2001 04:26:06 GMT
> 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).

> 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.

> 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.

> > 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


View raw message