#5421: <<loop>> in withMVar (reproducible, but with large test case)
-------------------------------+--------------------------------------------
Reporter: JohnMillikin | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.2.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
-------------------------------+--------------------------------------------
Comment(by simonpj):
That is indeed a strange thing to do. (Thinking aloud.) Internally what
happens is that the mfix code generates something like this:
{{{
main :: State# -> (State#, ())
main s = case newMVar () of { (s', mvar) ->
letrec
client = snd t
t = helper client s' -- THUNK BUILD HERE
in (fst t, ())
}
helper :: MVar () -> State# -> (State#, MVar ())
helper client s' = case fork (mainLoop client) of { (s'', ()) ->
case delay 5000 s'' of { (s''', ()) ->
return (s''', ()) } }
}}}
The `mfix` builds a thunk `t`, which it immedaitely begins to poke on (by
evaluating `fst t`). That spawns the other thread, and delays. At this
point the thunk is still under evaluation. The scheduler switches
threads, and I would have thought that it blackholed the thunk at that
moment (which would have led to a visible `<<loop>>`, but apparently not.
Simon M what do you think?
Does the same happen if you run on just one core?
The thunk `t` does IO and so we should be super-careful not to duplicate
its work. We are super-cafeful in some circumstances (like
`unsafePerformIO`) but I'm not sure we are super-careful here. Simon?
Thanks for boiling this down.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5421#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
