RE: unexpected thread blocking

> Actually I am not sure if this is really a bug, but anyway 
> the following 
> program
> behaves in different manners between with and without -O.
> Interestingly, ghci provides the same (expected) behavior as -O.
> 
> \begin{code}
> 
> import Control.Concurrent
> import Control.Concurrent.MVar
> import IO(hPutStrLn, stderr)
> 
> main = do
>         mvar <-newEmptyMVar     hPutStrLn stderr "forking..."
>         thread <-forkIO (undef `seq` (putMVar mvar hoge))
>         isEmpty <-isEmptyMVar mvar
>         hPutStrLn stderr ("isEmpty = " ++ show isEmpty)
> 
> undef = undef
> hoge  = "hoge"
> 
> \end{code}
> 
> Results:
>   $ ghc testConcurrent.lhs -o tto.exe
>   $ tto.exe
>   forking...
>   isEmpt<<<DOES NOT COME BACK>>>
> 
>   $ ghc testConcurrent.lhs -o tto.exe -O
>   $ tto.exe
>   forking...
>   isEmpty = True

I suspect, without running the program, that you've run into a known
problem with the way GHC implements concurrency.

In GHC, context switches are triggered by memory allocation.  If the
computation is doing no allocation, then it will never context switch,
which is why you get an infinite loop in your example (undef is a
recursive function which never allocates).  When -O is turned on, the
compiler probably spots that undef is equal to _|_ and uses that fact to
eliminate undef.

The workaround is simple: use Prelude.undefined or Prelude.error instead
of undef.

We should really fix this problem, but it's never been a high priority
because it happens so rarely and the workaround is usually easy.

Cheers,
        Simon