[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