Taru Karttunen wrote:
Excerpts from Bardur Arantsson's message of Wed Feb 17 21:27:07 +0200 2010:
For sendfile, a timeout of 1 second would probably be fine. The *ONLY*
purpose of threadWaitWrite in the sendfile code is to avoid busy-waiting
on EAGAIN from the native sendfile.
Of course this will kill connections for all clients that may have a
two second network hickup.
I'm not talking about killing the connection. I'm talking about retrying
sendfile() if threadWaitWrite has been waiting for more than 1 second.
If the connection *has already been closed* (as detected by the OS),
then sendfile() will fail with EBADF, and we're good.
If the connection *hasn't been closed*, there are two cases:
a) Sendfile can send more data, in which case it does and we go back
to sleep on a threadWaitWrite.
b) Sendfile cannot send more data... in which case the sendfile
library gets an EAGAIN and goes back to sleep on a threadWaitWrite.
I don't see how that would lead to anything like what you describe.
How so? As a user I expect sendfile to work and not semi-randomly block
threads indefinitely.
If you want sending something to terminate you will add a timeout to
it. A nasty client may e.g. take one byte each minute and sending your
file may take a few years.
This can always happen. The timeout here is at the application level
(e.g. "has this connection been open too long") and sendfile shouldn't
concern itself with such things.
The point with my proposed fix is that sendfile will be reacting to the
OS's detection of a dropped connection ASAP (plus 1 second) rather than
just hanging.
Cheers,
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
