[Haskell-cafe] sendfile leaking descriptors on Linux?

[Jeremy Shaw]

Well, that's not good.

I wonder how we are supposed to know that the client has disconnected... We
use withBinaryFile to open the file, so if an uncaught except is being
thrown then that should close the file handle..

If you look in Network.Socket.SendFile.Linux, you will see that when the C
sendfile() function returns -1, we throw an exception, unless it is the
EAGAIN error. So, that should cause us to close the files when an error
occurs.

There is one possible odd case.. if sendfile returns 0, then we assume
nothing went wrong and keep trying to resend the data until everything is
sent. If it keeps returning 0 then we just keep trying even though nothing
is happening. (Or if we keep getting EAGAIN errors..). But I am not sure
that either of these cases would actually happen in practice.

Another cause might be if threadWaitWrite is just never returning after the
client disconnects..

- jeremy



On Thu, Feb 4, 2010 at 1:43 PM, Bardur Arantsson <spam at scientician.net>wrote:

> Hi all,
>
> I've been using the sendfile package off Hackage, but it seems to be
> leaking file descriptors when using the Linux-native build.
>
> What's happening in my specific case is the following:
>
>   1) client requests a range of a file
>   2) server starts sending the range
>   3) client disconnects before receiving the whole file
>
> This happens over and over with the client requesting different ranges of
> the file (so the client does make progress).
>
> If I use the portable build of the sendfile package, everything works fine
> for hours and hours of this happening.
>
> If I use the Linux-native build of the sendfile package, the server
> will eventually run out of file descriptors. According to "lsof" the files
> that are being kept open are the data files being sent in 2) above.
>
> This is on GHC 6.10.x (Ubuntu).
>
> Is anyone else seeing this? Anyone got any idea what's going on?
>
> Cheers,
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100204/666b0e5e/attachment.html