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
The difference also applies for more complicated programs.
Since both ghc-5.04-2 on WinXP and ghc-5.04-1 on Solaris 8 yield the same result,
it is quite likely that the problem is platform independent.
Thank you very much.
- Susumu
% BTW, what I want to do is something like
% undef = length hoge
% hoge = somethingLazy -- result of auto-generated module that may not terminate.
% or I may well say that I need takeMVar with a timeout parameter.
% I would appreciate also if someone knows a good workaround other than giving -O/--interact.
_______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
