On Thu, Jan 17, 2002 at 11:08:37PM -0500, Greg Ames wrote: > No, you have to look at how sendfile_it_all interacts with apr_sendfile and the > kernel. It blocks in select() until the kernel is happy with the amount of room > in its socket buffers. Then the select returns to apr_sendfile, which issues > the next sendfile which will send some data (a multiple of 4k usually on > daedalus) but returns with -1 errno 35 anyway. We change the retval to 0, > forget that the kernel warned us about blocking, and unwind to sendfile_it_all. > It updates its offset and length to account for what was sent, and calls > apr_sendfile again. apr_sendfile issues another sendfile right away, which is > almost always doomed to get -1 errno 35 with no bytes sent. (This unproductive > sendfile call could be eliminated by remembering that the kernel told us it > would block across apr_sendfile invocations.) Then we call select and block and > start over.
Yes, I see that now. If I get a chance I'll try to add the APR_INCOMPLETE_foo state you were talking about. Is there a reason we don't just call sendfile in blocking mode? -aaron
