[Haskell-cafe] GHC, odd concurrency space leak

Neil Brown nccb2 at kent.ac.uk
Thu Apr 15 04:37:35 EDT 2010

Jason Dagit wrote:
> On Wed, Apr 14, 2010 at 3:13 PM, Daniel Fischer 
> <daniel.is.fischer at web.de <mailto:daniel.is.fischer at web.de>> wrote:
>     Am Mittwoch 14 April 2010 23:49:43 schrieb Jason Dagit:
>     > > It will be interesting to hear what fixes this!
>     > >
>     > >
>     > > forever' m = do _ <- m
>     > >                 forever' m
>     >
>     > When I define that version of forever, the space leak goes away.
>     Not with optimisations.
> Thanks for pointing that out.  I forgot to say so in my email.
> Here are two reduced versions of the original program:

I find non-termination with a much simpler program than yours (GHC 6.12.1):

\begin{code}{-# OPTIONS -O1 #-}

import Control.Concurrent
import Control.Monad (forever)

main = do
   putStrLn "Main thread starting"
   forkIO $ do putStrLn "Started thread"
               forever $ return ()
   putStrLn "Delaying"
   threadDelay (1 * 1000000)
   putStrLn "Delayed"

If I compile that with "ghc --make -threaded" and run it, with -O1 or 
-O2, it burns CPU and never terminates.  With -O0 it terminates.  So 
looks like some optimisation is causing the problem.

I might guess it's something to do with the RTS and threadDelay that's 
causing the problem.  "Delayed" is never printed on my system, so it 
seems like (even when run with +RTS -N2) the original thread is not ever 
being rescheduled; perhaps the timeout queue isn't checked properly when 
a thread is burning up the CPU like that, and optimisations are on?



More information about the Haskell-Cafe mailing list