Code without MVar: "thread blocked indefinitely in an MVar operation"

[cobb]

The attached code produces the above message when compiled with optimisations on - even -O1 is enough. The same happens on both 32 and 64-bit architectures.

[simonmar]

commit 9ab1f46d601e0f4c4582a1a77d9b4c26bf166daa
Author: Simon Marlow <marlowsd@gmail.com>
Date:   Fri Mar 23 12:28:18 2012 +0000

    change unsafeDupableInterleaveIO from INLINE to NOINLINE (#5943)
    
    See the comment for details.

[pcapriotti]

Merged as b5ae8e3f64218f45c845c4aac2d05d967cfd6ba6.

[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.