[Haskell-cafe] Re: sendfile leaking descriptors on Linux?

[Bardur Arantsson]

Jeremy Shaw wrote:
> On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson <spam at 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,