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_simple_split
Date Mon, 27 Aug 2001 08:13:21 GMT
On Mon, Aug 27, 2001 at 12:00:33AM -0500, William A. Rowe, Jr. wrote:
>...
> If a bucket represents a networkable/readable/writable part of a conversation,

Here is the problem. A bucket represents *data*. It is entirely independent
of the network, or in-memory handling, or persisting to disk, or what have
you.

Data. Pure and simple.

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

The sendfile problem that you bring up is related to the code that delivers
a brigade over a socket. It has nothing to do with buckets or those
brigades.

I just did a search over the code. There are seven instances of code
creating FILE buckets. Not a single one of them checks to ensure the file
length is within the scope of an apr_size_t. But there is no reason they
should. Those buckets represent file contents. Not "file contents, as long
as that can fit in memory."

Buckets are data.

Buckets are not "sendfile-sized chunks of data."


As with Roy, I am entirely for consistency of the API, and the work that you
did to clean it up is Good. But apr_off_t is the real, potential size of a
bucket's data.

(and yes, I could also agree with tossing the platform-specific apr_off_t
 and saying they are apr_int64_t or apr_uint64_t (if the latter, then we
 would need a const for the "-1" concept we have now))

Cheers,
-g

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

Mime
View raw message