Aaron Bannert wrote: got my nose out of the ktraces finally, so I re-read this a little closer. > A quick glance at sendfile_it_all in server/core.c looks to me > like it would loop repeatedly on that error condition, as we are seeing > it in the ktrace output.
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. Greg
