
Jason Dagit wrote:
On Wed, Apr 14, 2010 at 3:13 PM, Daniel Fischer
mailto:daniel.is.fischer@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:
<snip> 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" \end{code} 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? Thanks, Neil.