httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: questions on ap_sendfile() and non-blocking sockets
Date Tue, 27 Jun 2000 15:26:30 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.

I would agree.

> 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.

I think, and I haven't really reviewed this stuff yet, that we need
something like like_for_io_or_timeout.  HEre's what I mean:

If we are trying to send a 100MB file with a 30 sec timeout, and the first
call to sendfile sends 10 MB, and then the socket tells us to block.  ten
seconds later we send another 10 MB file, we need to reset the
timeout.  The timeout is, in my mind at least, the longest we are willing
to try as long as we are failing.  Does that make sense?  Do other feel
the same way?

> 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.

You say this so much better then I did above.  YES, YES, a thousand times
YES!  :-)

> 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.

I disagree.  If there is no timeout, then APR should continue to try to
send the data until we recieve an error from sendfile.  APR was told to
send the data for as long as it takes.  We should honor that request.  I
may be wrong about this, these are just my opinions.

> 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

If I understand you, yes.  If I don't, I'll catch what you mean when I see
the code.  :-)

> Speak up now if you disagree :)

Looks good for the most part.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message