#5943: Code without MVar: "thread blocked indefinitely in an MVar operation"
---------------------------+------------------------------------------------
Reporter: cobb | Owner: simonmar
Type: bug | Status: closed
Priority: high | Milestone: 7.4.2
Component: Compiler | Version: 7.4.1
Resolution: fixed | Keywords:
Os: Linux | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
---------------------------+------------------------------------------------
Comment(by simonpj):
Comments from the commit
{{{
-- We used to believe that INLINE on unsafeInterleaveIO was safe,
-- because the state from this IO thread is passed explicitly to the
-- interleaved IO, so it cannot be floated out and shared.
--
-- HOWEVER, if the compiler figures out that r is used strictly here,
-- then it will eliminate the thunk and the side effects in m will no
-- longer be shared in the way the programmer was probably expecting,
-- but can be performed many times. In #5943, this broke our
-- definition of fixIO, which contains
--
-- ans <- unsafeInterleaveIO (takeMVar m)
--
-- after inlining, we lose the sharing of the takeMVar, so the second
-- time 'ans' was demanded we got a deadlock. We could fix this with
-- a readMVar, but it seems wrong for unsafeInterleaveIO to sometimes
-- share and sometimes not (plus it probably breaks the noDuplicate).
-- So now, we do not inline unsafeDupableInterleaveIO.
}}}
See also #5859.
--
Ticket URL: <
http://hackage.haskell.org/trac/ghc/ticket/5943#comment:4>
GHC <
http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Locked
