apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: apr_buckets_file.c:file_read + XTHREAD
Date Wed, 28 Nov 2001 03:16:28 GMT
From: "Ryan Bloom" <rbb@covalent.net>
Sent: Tuesday, November 27, 2001 9:12 PM


> On Tuesday 27 November 2001 07:02 pm, Doug MacEachern wrote:
> 
> This seems straightforward to me.  The bucket read function doesn't
> make sense in this case, because we know that we are going to read
> the entire file, and throw all of it away without ever actually using the
> data once it has been encrypted.
> 
> In this case, the SSL module should just read from the file directly.  It is
> kind of hokey, but that is because SSL just doesn't fit our filter model.  The
> filters are written to allow for zero-copy, but SSL isn't a zero-copy
> operation in this case.

Bzzt... wrong.  There are plenty of non-zero copy operations in the world... this
isn't the 'unique exception' ... it will be frequent enough to warrent redesign.

> Perhaps a better solution would be to just create a read function that
> accepts a pre-allocated buffer that we must copy into.  Then, filters that
> know they are going to throw the data away would incur the penalty of the
> copy in lieu of the penalty of the malloc().  With the file bucket, this has the
> advantage that the read from the disk can be put directly into the 
> pre-allocated buffer, and the copy doesn't actually exist.

Bingo.  That way you haven't tied it up with specific bucket types - but extended
the api for all buckets.

This is where I keep saying that the consumer often knows more about the mechanics
of transfering or processing the data than the producer... until we add some
graceful methods for handling those cases, kludges will abound.

Bill


Mime
View raw message