#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