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 <s...@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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
