[GHC] #4154: Deadlock in Chan module

[GHC]

#4154: Deadlock in Chan module
-------------------------------------+-------------------------------------
        Reporter:  NeilMitchell      |                Owner:  (none)
            Type:  bug               |               Status:  closed
        Priority:  high              |            Milestone:  8.4.1
       Component:  libraries/base    |              Version:  6.12.3
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by bgamari):

 * milestone:  7.0.1 => 8.4.1


Old description:

> The following program:
>
> {{{
> module Main where
>
> import Control.Concurrent
>
> main :: IO ()
> main = do
>     todo <- newChan
>     forkIO $ readChan todo
>     putStrLn "Before isEmptyChan"
>     b <- isEmptyChan todo
>     putStrLn "After isEmptyChan"
>     writeChan todo ()
> }}}
>
> Gives the output:
>
> {{{
> $ ghc --make Main.hs -threaded && ./Main.exe
> Before isEmptyChan
> Main.exe: thread blocked indefinitely in an MVar operation
> }}}
>
> I think that's a bug. Note that if the {{{putStrLn}}} statements are
> removed then it works, but I think that's because the printing introduces
> a delay that lets the other thread run.

New description:

 The following program:

 {{{#!hs
 module Main where

 import Control.Concurrent

 main :: IO ()
 main = do
     todo <- newChan
     forkIO $ readChan todo
     putStrLn "Before isEmptyChan"
     b <- isEmptyChan todo
     putStrLn "After isEmptyChan"
     writeChan todo ()
 }}}

 Gives the output:

 {{{
 $ ghc --make Main.hs -threaded && ./Main.exe
 Before isEmptyChan
 Main.exe: thread blocked indefinitely in an MVar operation
 }}}

 I think that's a bug. Note that if the {{{putStrLn}}} statements are
 removed then it works, but I think that's because the printing introduces
 a delay that lets the other thread run.

--

Comment:

 Indeed, let's delete them for 8.4. I've opened #13561 to make sure we
 don't forget this.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler