Date: Fri, 12 Nov 1999 01:32:00 -0600
From: Manoj Kasichainula <manojk@io.com>
To: new-httpd@apache.org
Subject: Re: [PATCH] Whoops, here's the better Linux sendfile()
Message-ID: <19991112013200.A8114@io.com>
Mail-Followup-To: new-httpd@apache.org
References: <19991111003550.A30656@samosa.mindspring.com>
 <382B15C3.657265BD@princeton.edu> <19991104171743.A1447@dosa.raleigh.ibm.com>
 <3823B9D1.576DBCB0@princeton.edu>
 <000d01bf2818$fb09c1b0$a78fe120@raleigh.ibm.com>
 <38252A80.DD304A88@princeton.edu> <382533FF.EB7F121B@princeton.edu>
 <19991111003550.A30656@samosa.mindspring.com>
 <19991111184242.A21818@dosa.raleigh.ibm.com>
 <382B637D.426104F4@princeton.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <382B637D.426104F4@princeton.edu>;
 from zedlwski@Princeton.EDU on Thu, Nov 11, 1999 at 07:46:53PM -0500
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

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/