Bardur Arantsson wrote:

(sorry about replying-to-self)

During yet another bout of debugging, I've added even more "I am here" instrumentation code to the SendFile code, and the culprit seems to be
> threadWaitWrite.

I think I've pretty much confirmed this.

I've changed the code again. This time to:

> sendfile :: Fd -> Fd -> Ptr Int64 -> Int64 -> IO Int64
> sendfile out_fd in_fd poff bytes = do
>     putStrLn "PRE-threadWaitWrite"
>     -- threadWaitWrite out_fd
>     -- putStrLn "AFTER threadWaitWrite"
>     sbytes <- c_sendfile out_fd in_fd poff (fromIntegral bytes)
>     putStrLn $ "AFTER c_sendfile; result was: " ++ (show sbytes)
>     if sbytes <= -1
>       then do errno <- getErrno
>               if errno == eAGAIN
>                 then do
>                    threadDelay 100
>                    sendfile out_fd in_fd poff bytes
>                 else throwErrno "Network.Socket.SendFile.Linux"
>      else return (fromIntegral sbytes)

That is, I removed the threadWaitWrite in favor of just adding a
"threadDelay 100" when eAGAIN is encountered.

With this code, I cannot provoke the leak.

Unfortunately this isn't really a solution -- the CPU is pegged at
~50% when I do this and it's not exactly elegant to have a hardcoded
100 ms delay in there. :)

I'm hoping that someone who understands the internals of GHC can chime
in here with some kind of explanation as to if/why/how threadWaitWrite can
fail in this way.

Anyone?

Cheers,

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to