[GHC] #5943: Code without MVar: "thread blocked indefinitely in an MVar operation"

[GHC]

#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