httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@raleigh.ibm.com>
Subject Re: [PATCH] Whoops, here's the better Linux senfile()
Date Thu, 11 Nov 1999 23:42:42 GMT
On Thu, Nov 11, 1999 at 12:35:51AM -0500, Me at IO wrote:
> The patch looks great.

Hmmm, now that I'm looking at it more carefully, I see a couple of
problems. One is the noted ignoring of the "header" argument.

Also, I don't believe that Linux sendfile actually guarantees that it
will write all the bytes requested; AFAIK it works just like the other
IO functions. I guess we could add a loop to make sure that the
sendfile call completes all the bytes, but that would be inconsistent
with the way the other IOL functions work.


On Thu, Nov 11, 1999 at 02:15:15PM -0500, John Zedlewski wrote:
> - Both Linux and FreeBSD allow you to specify an offset into the file in
> the sendfile() API.  I don't believe that Win32 TransmitFile() allows
> this.

Can it be simulated by fseeking (or whatever the Windows version is
called) before calling TransmitFile? If so, then we can simulate the
offset.

> How often in practice is ap_send_fd_length really used to
> transmit files of a decent size?

ap_send_fd_length is used when a byte range is requested, which I
imagine happening when a (probably long) request gets cut off in the
middle and we wish to restart it. So I would think it would mostly be
used for large files.

On Thu, Nov 11, 1999 at 02:58:20PM -0500, Bill Stoddard wrote:
> ap_status_t ap_sendfile(struct iovec *headers, struct iovec *trailers,
> ap_file_t *file, int flags)

As an aesthetic change, I'd like to see *trailers after *file, since
the trailers are actually sent after the file. And both Linux and NT
support a number_of_bytes parameter. This all results in:

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

BTW, the Windows propensity (and necessity) to cram 47 different
functions into one system call makes me sick in the stomach. bleh.

This call won't be guaranteed to write all its bytes, though this will
only be an issue on Unix.

Thoughts?

-- 
Manoj Kasichainula - manojk@raleigh.ibm.com
IBM, Apache Development

Mime
View raw message