You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by John Zedlewski <ze...@Princeton.EDU> on 1999/11/06 06:17:05 UTC
Sendfile()
I just joined this list recently and caught the tail end of a discussion
about a patch to use the sendfile() API in Linux and other systems in
Apache. I'd been working on a similar adjustment and, while I had it
working, I wasn't really happy with it. Could somebody send me a copy of
that patch so I could play around with it and see the approach it takes?
I'd really appreciate it.
Thanks!
--JRZ
Re: Profiling
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I am assuming you are on Linux, but regardless, you HAVE to compile using
-DGPROF. This is a define that disables profiling in the parent and
enables it in the children. It's a good idea to use it whenever using
GPROF, and it is required when using gprof with Apache on Linux.
Ryan
On Mon, 8 Nov 1999, John Zedlewski wrote:
> This is a fairly stupid question, I know, but I can NOT get apache to compile and produce a usable gmon.out for use with
> gprof and it's driving me crazy. I tried just "make OPTIM=-pg", but the only gmon.out that creates is in the main
> directory and gprof reports that it doesn't contain the necessary symbols. Is there a simple way to get gprof to work
> with it?
> Thanks a lot!
> --JRZ
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Profiling
Posted by John Zedlewski <ze...@Princeton.EDU>.
This is a fairly stupid question, I know, but I can NOT get apache to compile and produce a usable gmon.out for use with
gprof and it's driving me crazy. I tried just "make OPTIM=-pg", but the only gmon.out that creates is in the main
directory and gprof reports that it doesn't contain the necessary symbols. Is there a simple way to get gprof to work
with it?
Thanks a lot!
--JRZ
Re: [PATCH] ap_sendfile try #1
Posted by Greg Stein <gs...@lyra.org>.
On Fri, 12 Nov 1999, John Zedlewski wrote:
> Well, here's an initial look at an implementation for ap_sendfile in the Unix
> APR. I work on Linux, but I also wrote (untested) versions for the HP-UX and
> FreeBSD APIs so I could see how different they'd be. Currently, the three
> OS-specific versions are completely separate. What will be the neatest way to
> format these eventually?
Uh oh.. don't go there... :-)
We had this "discussion" a while back on the list. Some people said to
share the function definition and #ifdef the interior contents; others
said to #ifdef the entire function (including the definition line(s)).
I think the end result was "whoever implements the code will use their
preferred pattern, but people can always go through and retrofit if it
spins their bottle."
About the patch you attached. Couple things:
1) there is a lot of extraneous, unrelated stuff that appears to be a diff
caused by formatting/spacing differences. That should be removed from
the patch so that it is easier to look at the "real" change.
2) the patch is reversed. All your changes have "-" in front of them,
rather than adding the lines :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] ap_sendfile try #1
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Fri, 12 Nov 1999, John Zedlewski wrote:
> Well, here's an initial look at an implementation for ap_sendfile in the Unix
> APR. I work on Linux, but I also wrote (untested) versions for the HP-UX and
> FreeBSD APIs so I could see how different they'd be. Currently, the three
> OS-specific versions are completely separate. What will be the neatest way to
> format these eventually? AIX is quite weird, but it does fit with the interface
> described above and I can give a crack at it some time soon if this format turns
> out to be acceptable.
As Greg said, there have been multiple discussions about this in the past.
The rule I have been working with is if >50% of the code is common try to
put everything in one function and use #ifdef's. If < 50% of the code is
common, just #ifdef around the whole function.
As a side note, I had a chance to look through some code that used the
always #ifdef the code within the function earlier this week. I couldn't
read it. I couldn't follow which ifdef was for which platform, and it
only dealt with three platforms. Everybody else I showed the code to
also had the same problem.
> This stuff is REALLY platform-specific, but at least it's all going to be stuck
> in APR instead of trailing throughout the main code. I suspect there will be
> some issues/objections with this code, so I didn't make the necessary changes to
> get http_core to use the new API or to change the Win32 interface. I can do that
> when/if a final version is decided upon.
Could you please clean up the patch a bit. Greg had a couple of good
points, but there is more cleaning needed as well.
1) Please try to keep the lines wrapping nicely, it just makes the code
easier to look at.
2) Please remove all of the printf's. This is a library function, and
the printf's don't make sense in a library function. You should be
returning sensable error codes (Errno in most cases), and if you need to
document why it failed, use comments.
3) There is no reason for ap_sendfile (an APR function) to use
ap_get_os_file, inside APR, the compiler won't complain if you just grab
the field from the structure.
4) Please review the Apache style guide (on dev.apache.org) and the
APRDesign (from 2.0 CVS tree) docs. Your format is a little off, and
either it needs to be fixed in the next patch or whoever applies the
patch has to do it by hand. It is easier for you to just fix it for the
next patch.
5) Please put docs into the code above the first copy of ap_sendfile.
The format for APR docs is relatively easy, and can be seen above ALL of
the current APR functions.
I'll look at it in more detail later today.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
[PATCH] ap_sendfile try #1
Posted by John Zedlewski <ze...@Princeton.EDU>.
Well, here's an initial look at an implementation for ap_sendfile in the Unix
APR. I work on Linux, but I also wrote (untested) versions for the HP-UX and
FreeBSD APIs so I could see how different they'd be. Currently, the three
OS-specific versions are completely separate. What will be the neatest way to
format these eventually? AIX is quite weird, but it does fit with the interface
described above and I can give a crack at it some time soon if this format turns
out to be acceptable.
ap_sendfile( ) should, as I think Manoj pointed out, work just like read or
write: it might not do a full write, but it stores the number of bytes written in
*len. It would fail to write the complete number if (a) It's used on a
non-blocking socket, or (b) it's interrupted by a signal.
This stuff is REALLY platform-specific, but at least it's all going to be stuck
in APR instead of trailing throughout the main code. I suspect there will be
some issues/objections with this code, so I didn't make the necessary changes to
get http_core to use the new API or to change the Win32 interface. I can do that
when/if a final version is decided upon.
Thanks!
--JRZ
Re: [PATCH] Whoops, here's the better Linux sendfile()
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 12 Nov 1999, Manoj Kasichainula wrote:
> 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.
get an app to write() more than the socket buffer can hold, so that it has
to block, and then strace it... or ^Z/fg it.
Dean
Re: [PATCH] Whoops, here's the better Linux sendfile()
Posted by Manoj Kasichainula <ma...@io.com>.
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/
Re: [PATCH] Whoops, here's the better Linux sendfile()
Posted by John Zedlewski <ze...@Princeton.EDU>.
> 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.
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." In my experience, I've
never seen sendfile() fail to send the whole file without some kind of real
error. It's worth looking at the implementation, though, which I'll do when
I get a chance. Generally, it seems that ap_sendfile should guarantee
sending the whole file unless an error occurs, because otherwise one would
just use read/write. Still, I agree it needs more investigation.
> 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? God, this is becoming a bear. I have it almost done for a couple of
different OSes now and should be able to submit it later tonight. The
interface should be easy enough to change around.
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.
Then we'd have:
ap_status_t ap_sendfile( ap_socket_t *socket,
ap_file_t *file,
ap_hdtr_t *hdtr,
ap_off_t *offset,
ap_size_t *len,
ap_int_n flags,
)
And:
struct ap_hdtr_t {
struct iovec* headers;
int numheaders;
struct iovec* trailers;
int numtrailers;
};
Then len gets overwritten with the number of bytes successfully written to
the socket, just as len gets overwritten in ap_send. That is, if we don't
make it guarantee a complete write. This also keeps it to 6 arguments, which
is generally the max I like to see in a function, but maybe that's just me.
--JRZ
Re: [PATCH] Whoops, here's the better Linux senfile()
Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.
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
Re: sendfile() / Moving iol_socket to APR / abstractions in http_core
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
>
> Sounds great. I actually have been wondering, though, about the
> interface for the sendfile method in ap_iol_methods
The current interface was an experiment and is going to change. The
generalized sendfile API needs to accomodate sending an arbitrary number of
header buffers, the actual file followed by an arbitrary number of trailer
buffers. The new interface will look something like this:
ap_status_t ap_sendfile(struct iovec *headers, struct iovec *trailers,
ap_file_t *file, int flags)
The API needs to accomodate sending header and trailer data in a single
sendfile system call even if Apache does not initially use it.
> The current implementation also leaves a #ifdef
> HAVE_SENDFILE in ap_send_fd.
> So I think this leaves us with a few possibilities to consider:
> - Eliminate the #ifdefs in the main code by abstracting in APR. This
> would mean using ap_sendfile in ap_send_fd and providing a new
> implementation of ap_sendfile for OSes that don't have the actual system
> call.
That 'new implementation' would be ap_send_fd_length and I'm not sure it
belongs in APR. Still, this is an idea worth exploring.
> There could actually be some good reasons for
> perfomance to have the sendfile method send the headers (particularly by
> setting the sockopt TCP_CORK on Linux), and I assume this is the reason
> why those args are there in the first place.
Yep, that's the reason. And I suspect the performance impact if very OS
specific. On Windows, system calls are mongo expensive so it's best to avoid
them when possible.
> However, we'd need to
> implement an ap_get_http_reader function to do exactly what
> ap_send_http_header currently does, but return a string instead of
> actually sending it.
You can hack it today if you want to do quick and dirty performance
comparisons (but do not check it in). Notice I flush the client buffer
before calling sendfile. I can easily grab the data pointer and length out
of the buff and pass them in on the sendfile call.
> This might come in handy for other modules or
> performance tweaks that want to send the header in their own way.
> - It seems to me that sendfile() and mmapped files are mutually exclusive
> strategies to quickly transmit an entire file.
Correct.
> If we moved the mmap code
> from default_handler to the new ap_sendfile, it would eliminate a lot of
> #ifdef'd cruft from the main module. This would put all the
> platform-specific performance tweaks into APR where they, IMHO, probably
> should be. We can always provide a NO_MMAP flag for ap_sendfile that
> ensures no memory mapping will be used, if in some case it would be
> undesirable.
> - 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.
It does. I don't recall the details though.
> By the way, I've heard that HP-UX also has a sendfile() call. Is that
> accurate?
Yes, HP has sendfile.
> Any other platforms?
Yes, AIX has sendfile too. Unfortunately each version handles headers and
trailers differently. Bleh.
Bill
Re: sendfile() / Moving iol_socket to APR / abstractions in http_core
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Okay, lots of stuff here, one thing at a time.
> So I think this leaves us with a few possibilities to consider:
> - Eliminate the #ifdefs in the main code by abstracting in APR. This
> would mean using ap_sendfile in ap_send_fd and providing a new
> implementation of ap_sendfile for OSes that don't have the actual system
> call. That would be a simple, standard read/write loop. This seems like
> a necessity to allow APR to truly provide the same API on all platforms.
> - It seems to me that sendfile() and mmapped files are mutually exclusive
> strategies to quickly transmit an entire file. If we moved the mmap code
> from default_handler to the new ap_sendfile, it would eliminate a lot of
> #ifdef'd cruft from the main module. This would put all the
> platform-specific performance tweaks into APR where they, IMHO, probably
> should be. We can always provide a NO_MMAP flag for ap_sendfile that
> ensures no memory mapping will be used, if in some case it would be
> undesirable.
If I understand you properly, you want APR to implement ap_sendfile, and
you want ap_sendfile to either use sendfile or mmap under the covers,
depending on what the platform provides.
I agree with the first half, and it's coming. We are going to put
sendfile into APR. Somebody just has to do it. I haven't had the time
recently, and I haven't seen any patches yet. hint hint.
I disagree completely with the second part. APR will provide feature
macros, APR_HAS_SENDFILE and APR_HAS_MMAP. Let Apache decide which of
these should be used and when. ap_sendfile should implement sendfile and
only sendfile. If sendfile doesn't exist, then we won't define that
feature macro. apr_mmap_* should use mmap and only mmap, again if mmap
doesn't exist on a given platfrom, APR_HAS_MMAP won't be defined.
> - 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. It would allow ap_send_fd_length to be implemented with sendfile
> as well. How often in practice is ap_send_fd_length really used to
> transmit files of a decent size? I have no idea whether this change
> would make a noticeable performance difference, so it probably isn't
> worth doing unless Win32 does have some hidden offset specification.
I suggest ignoring this for now, and maybe coming back to it in the near
future.
> I think that these little changes could clean up http_core and the
> default handler significantly, while also making APR more useful and
> improving performance. I'd be glad to do the patches myself, if you all
> think it's a reasonable strategy.
Any patches that are submited will be considered. I say give us the code,
and let's take a look. :)
> Finally, I'd like to put in a vote for the "option 1" method of
> incorporating iol_socket into APR (the non-linked-list version). It
> seems much simpler and I don't really see a performance difference.
Afraid I don't understand what you mean. The only discussion of linked
lists was in the second half of the note, and both options involved linked
lists. The second half of the note was only intended to show where IOL's
will be going at some point. AFAIK, we have decided not to put layering
into 2.0, because we want to put a stable release out soon, and layering
just adds to much new feature to 2.0.
The top half of the note had more to do with the 2.0 design, namely should
APR types be filling in the function pointers, or should IOL's have their
own types with their own functions?
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
sendfile() / Moving iol_socket to APR / abstractions in http_core
Posted by John Zedlewski <ze...@Princeton.EDU>.
> The patch looks great. It covers everything I wanted to see when I
> thought about writing it. :) I'll test it a bit and hopefully commit
> it tomorrow. I like TCP_CORK though, so I want to uncomment those
> setsockopts.
>
> Hopefully, we can put this into APR at some point.
Sounds great. I actually have been wondering, though, about the
interface for the sendfile method in ap_iol_methods. I used the one that
already existed in ap_iol.h (in the include dir) and figured that some of
the strange arguments were necessary on Win32 for its TransmitFile
implementation. Here's the declaration:
"ap_status_t (*sendfile)(ap_iol *fd, ap_file_t *file, long size, const
char* header, long hdrlen, int flags)"
However, the only invocation of this method comes in http_protocol as:
"iol_sendfile( r->connection->client->iol, fd, len, NULL, 0, 0 )" (line
2013)
Actually, I can't see anywhere in win32_sendfile where header, hdrlen, or
flags are used. I also haven't used those args in the Unix version,
because default_handler, at least, calls "ap_send_http_header" before
calling ap_send_fd. The current implementation also leaves a #ifdef
HAVE_SENDFILE in ap_send_fd.
So I think this leaves us with a few possibilities to consider:
- Eliminate the #ifdefs in the main code by abstracting in APR. This
would mean using ap_sendfile in ap_send_fd and providing a new
implementation of ap_sendfile for OSes that don't have the actual system
call. That would be a simple, standard read/write loop. This seems like
a necessity to allow APR to truly provide the same API on all platforms.
- Either eliminate the header-related arguments or use them in the
default_handler. There could actually be some good reasons for
perfomance to have the sendfile method send the headers (particularly by
setting the sockopt TCP_CORK on Linux), and I assume this is the reason
why those args are there in the first place. However, we'd need to
implement an ap_get_http_reader function to do exactly what
ap_send_http_header currently does, but return a string instead of
actually sending it. This might come in handy for other modules or
performance tweaks that want to send the header in their own way.
- It seems to me that sendfile() and mmapped files are mutually exclusive
strategies to quickly transmit an entire file. If we moved the mmap code
from default_handler to the new ap_sendfile, it would eliminate a lot of
#ifdef'd cruft from the main module. This would put all the
platform-specific performance tweaks into APR where they, IMHO, probably
should be. We can always provide a NO_MMAP flag for ap_sendfile that
ensures no memory mapping will be used, if in some case it would be
undesirable.
- 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. It would allow ap_send_fd_length to be implemented with sendfile
as well. How often in practice is ap_send_fd_length really used to
transmit files of a decent size? I have no idea whether this change
would make a noticeable performance difference, so it probably isn't
worth doing unless Win32 does have some hidden offset specification.
I think that these little changes could clean up http_core and the
default handler significantly, while also making APR more useful and
improving performance. I'd be glad to do the patches myself, if you all
think it's a reasonable strategy.
By the way, I've heard that HP-UX also has a sendfile() call. Is that
accurate? Any other platforms?
Finally, I'd like to put in a vote for the "option 1" method of
incorporating iol_socket into APR (the non-linked-list version). It
seems much simpler and I don't really see a performance difference.
Thanks, folks,
--JRZ
Re: [PATCH] Whoops, here's the better Linux senfile()
Posted by Manoj Kasichainula <ma...@io.com>.
First, I'd suggest sending diffs to the list instead. See
<http://dev.apache.org/patches.html>. Since you're using Linux, use
"diff -u" instead of "diff -C3" to get unified diffs; they're much
prettier.
The patch looks great. It covers everything I wanted to see when I
thought about writing it. :) I'll test it a bit and hopefully commit
it tomorrow. I like TCP_CORK though, so I want to uncomment those
setsockopts.
Hopefully, we can put this into APR at some point.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: [PATCH] Whoops, here's the better Linux senfile()
Posted by John Zedlewski <ze...@Princeton.EDU>.
Sorry about that. I sent over the wrong version of the patch. Try this one instead:
[PATCH] Sendfile() for Linux
Posted by John Zedlewski <ze...@Princeton.EDU>.
Well, there was no sendfile() code for Unix/Linux in the CVS, so I went ahead
and adopted the WinNT TransmitFile() work over to Linux. Making it portable to
FreeBSD will take one or two little changes, but the API semantics are almost
the same. The biggest problem, as Mr. Stoddard suggested, is that, while
TransmitFile and sendfile seem very similar, the two functions have somewhat
different needs in terms of performance tuning. I haven't done any profiling
on this yet, so we'll see how it actually plays out. I also have a
sendfile() patch against 1.3.9, if anybody wants it.
--JRZ
Re: Sendfile()
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
Check out ap_send_fd in http_protocol.c in the Apache 2.0 repository for the
most recent stuff. It needs more work but it is enough to give you an idea.
The notable features are the feature macro, HAVE_SENDFILE, in ap_send_fd
that will call a sendfile API if the feature macro is defined on that
platform and parameters on the apache sendfile API to include an iovec of
headers a file descriptor (actually a file_t) of the file to send and an
iovec of trailer data.
Today, we send header data seperately and flush the buffer before calling
sendfile. Not optimal, but it helps performance on Windows NT for largish
files.
Bill
----- Original Message -----
From: John Zedlewski <ze...@Princeton.EDU>
To: <ne...@apache.org>
Sent: Saturday, November 06, 1999 12:17 AM
Subject: Sendfile()
> I just joined this list recently and caught the tail end of a discussion
> about a patch to use the sendfile() API in Linux and other systems in
> Apache. I'd been working on a similar adjustment and, while I had it
> working, I wasn't really happy with it. Could somebody send me a copy of
> that patch so I could play around with it and see the approach it takes?
> I'd really appreciate it.
> Thanks!
> --JRZ
>