httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: [PATCH] Whoops, here's the better Linux sendfile()
Date Fri, 12 Nov 1999 07:32:00 GMT
On Thu, Nov 11, 1999 at 07:46:53PM -0500, John Zedlewski wrote:
> Hmm... the man page says "if the transfer was succeeded, the number of bytes
> written to out_fd is returned. .  .  [offset] will be set to the offset of
> the byte following the last byte that was read."

The discussion I read on the linux-kernel list said it was
semanticly equivalent to read-then-write. And the man page doesn't
seem particularly polished to me, so it probably wasn't proofread.
But yeah, I have no real evidence to back up my claim.

> In my experience, I've
> never seen sendfile() fail to send the whole file without some kind of real
> error.

I've never personally witnessed it with read() or write() either :). I
went most of the way through finishing a class project a few years ago
without adding the loop around them until someone told me about the
partial-write semantics.

Also, I think sendfile supports nonblocking I/O, and we do want to
support a timeout on sendfile, so this requires allowing a partial
write on Unix.

> Generally, it seems that ap_sendfile should guarantee
> sending the whole file unless an error occurs, because otherwise one would
> just use read/write.

The advantage of a synchronous sendfile is that you save the extra
copy. This advantage doesn't go away with partial writes.

> > ap_status_t ap_sendfile(struct iovec *headers, ap_file_t *file,
> >                         struct iovec *trailers, ap_off_t *offset,
> >                         ap_ssize_t count, ap_int_n flags,
> >                         ap_size_t *bytes_written);
> 
> What about count arguments for both the number of headers and the number of
> trailers?  That seems to be the way most Unix OSes implement the header
> sending.  And, um, what about an ap_socket_t* onto which to write the
> output?

You're right about both of these.

> Maybe it would be smart to do what AIX and freebsd do: have a structure (
> ap_hdtr_t ) to hold the header iovec array, trailer iovec array, and lenghts
> of each.

This reduces the number of arguments you see in the call, but not the
*real* number of arguments. I'd prefer to find a way to reduce the
number of real arguments, but I don't think this is possible without
either screwing over Windows or dropping support for
ap_send_fd_length. Blah. I doubt I'll really complain about your
suggestion, since I can't think of a better alternative.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/

Mime
View raw message