httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@ibm.net>
Subject questions on ap_sendfile() and non-blocking sockets
Date Tue, 27 Jun 2000 13:54:44 GMT
1) how hard to try when APR_SO_TIMEOUT is specified

I would think that when a timeout has been set on the socket,
ap_sendfile() should not return until all data has been sent or the
timeout has expired.

Currently, inside ap_sendfile() there are at most two calls to
sendfile(), so sending a big file ain't gonna work if the socket is
non-blocking (which it is if APR_SO_TIMEOUT was specified).  This
needs to be remedied.

About the timeout...  For consistency with Apache use of socket
timeouts, I think we should allow arbitrary time to pass during the
sendfile() loop as long as we never have to wait longer than
sock->timeout for the socket to become writeable.  This may or may not
be what the arbitrary application writer expects.

2) About non-blocking sockets with no timeout (APR_SO_NONBLOCK):

ap_sendfile() should send whatever it can in one write-type call and
then return to the caller.  The caller needs to see that a partial
send took place, but the return code should be APR_SUCCESS if at least
one byte was written for consistency with other write-type APR calls.

3) Reporting bytes sent with APR_SO_TIMEOUT or APR_SO_NONBLOCK:

On input, parm 5 tells us how many bytes to send from the file.  We
update parm 5 on output with the total number of bytes sent (headers,
file content, trailers).  The caller can sort out what was sent and
what wasn't.  EAGAIN/EWOULDBLOCK is not an error (the caller is
supposed to know what they are doing), so parm 5 may be non-zero if we
return EAGAIN/EWOULDBLOCK.

Speak up now if you disagree :)

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message