On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson
I've tested this extensively during this weekend and not a single "leaked" FD so far.
I think we can safely say that polling an FD for read readiness is sufficient to properly detect a disconnected client regardless of why/how the client disconnected.
The only issue I can see with just dropping the above code directly into the sendfile library is that it may lead to busy-waiting on EAGAIN *if* the client is actually trying to send data to the server while it's receiving the file via sendfile(). If the client sends even a single byte and the server isn't reading it from the socket, then threadWaitRead will keep returning immediately since it's level-triggered rather than edge triggered.
Yeah. That could be trouble.
Not sure what the best solution for this would be, API-wise... Maybe actually have sendfile read the data and supply it to a user-defined function which could react to the data in some way? (Could supply two standard functions: "disconnect immediately" and "accumulate all received data into a bytestring".)
I think this goes beyond just a sendfile issue -- anyone trying to write non-blocking network code should run into this issue, right ? For now, maybe we should patch sendfile with what we have. But I think we really need to summarize our findings, see if we can generate a test case, and then see what Simon Marlow and company have to say... - jeremy