[Haskell-cafe] Possible bug in Control.Concurrent

Krzysztof Skrzętnicki gtener at gmail.com
Wed Feb 9 16:34:15 CET 2011


Hello Cafe,

Here is a simple program that yields strange results:

module Main where

import Control.Concurrent
import Control.Concurrent.Chan
import Control.Monad

main = do
 c <- newChan
 writeChan c 1
 forkIO $ forever $ do
   i <- readChan c
   print ("forkio",i)
isEmptyChan c >>= print

First of all, if we try to run it via runhaskell, it will hang:

runhaskell deadlock.hs
("forkio",1)
-- no more output --


Compiled version OTOH behaves differently dependent on compilation flags.
Without -threaded:
./deadlock
("forkio",1)
False

With -threaded:
./deadlock
False

Now, this is strange thing: we put single element into the channel. We take
it out. And then we see the channel isn't really empty. Perhaps there is a
race condition here? So we put an delay, so that we will be sure the check
for empty channel occurs 1 second later than the channel is emptied.

import Control.Concurrent
import Control.Concurrent.Chan
import Control.Monad

main = do
 c <- newChan
 writeChan c 1
 forkIO $ forever $ do
   i <- readChan c
   print ("forkio",i)
  threadDelay 1000000
 isEmptyChan c >>= print

This program will misbehave. Invariably of -threaded flag it will go like
this:

./deadlock
("forkio",1)
deadlock: thread blocked indefinitely in an MVar operation

I have no idea what is the problem here. Perhaps I'm not using the library
in the right way. Does anyone has any idea what's going on here?

Best regards,
Krzysztof Skrzętnicki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110209/8ff65ad9/attachment.htm>


More information about the Haskell-Cafe mailing list