Jeremy Shaw wrote:
On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson <s...@scientician.net>wrote:
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...
As far as I can tell, all nonblocking networking code is vulnerable to
this issue (unless it actually does use threadWaitRead, obviously :)).
In particular, I would imagine most of the Haskell HTTP servers are
vulnerable to this since they do use the same pattern of:
1) read all the input from the client connection,
2) send all the output to the client connection
where there is no reading from the socket in step 2.
I'm just not sure whether the GHC "built-in" I/O code *somehow*
avoids this problem. I think my tests indicate that it does, so it would
seem that it's only when you "go C" that you need to worry.
Re: a test case, you'll probably need to run the test case code on a
client whose OS allows (from userspace) the sudden dropping of
connections without sending a proper connection shutdown sequence. I'm
not sure that that OS would be.
Cheers,
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
