On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson <span dir="ltr">&lt;<a href="mailto:spam@scientician.net">spam@scientician.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>I&#39;ve tested this extensively during this weekend and not a single &quot;leaked&quot; FD so far.<br>
<br>
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.<br>
<br>
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&#39;s receiving the file via sendfile(). If the client sends even a single byte and the server isn&#39;t reading it from the socket, then threadWaitRead will keep returning immediately since it&#39;s level-triggered rather than edge triggered.<br>
</blockquote><div><br></div><div>Yeah. That could be trouble.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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: &quot;disconnect immediately&quot; and &quot;accumulate all received data into a bytestring&quot;.)<div>
<div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>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...</div>
<div><br></div><div>- jeremy </div></div>