apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr/network_io/unix sendrecv.c
Date Fri, 22 Dec 2000 02:25:50 GMT

> Rather than waiting for IO to be possible, doesn't the sendfile() return the
> number of bytes written? In other words, you would get EAGAIN *and* bytes
> written. Thus, you know not to send that data again.
> Seems like that would save a syscall for calls with timeout > 0.

There are a couple of problems with that.  If we know that some data has
been sent, then we have to figure out when that data ends, and re-send
from that location.  This duplicates logic that is already necessary in
the actual application.

The other option is to just try the sendfile, and if it sends anything,
just return, but if it doesn't then do the wait_or_timeout call.  This
complicates the code a bit, and in the case where we can't send
immediately, we end up with an extra syscall instead of removing one.

Basically, the approach I chose leverages logic that the application must
have regardless, and it means two syscalls for all cases, instead of one
syscall if the socket is available to write to, and three if it isn't.

This is really a toss up, but I chose to do it this way.  I am willing to
be convinced that the other way is better though.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message