GHC threading bug in QSem
ben.franksen at online.de
Wed Apr 8 14:20:36 EDT 2009
Chris Kuklewicz wrote:
> And really folks, the waitQSem(N) and signalQSem(N) should be exception
> safe and
> this is not currently true. They should all be using the modifyMVar_
> idiom — currently an exception such as killThread between the take and put
> will leave the semaphore perpetually empty which is not a valid state.
> I also hereby lobby that a non-blocking "trySem" be added, and while
> Control.Concurrent is getting updated I think that Neil's last concurrency
> puzzle would have been helped by having a non-blocking "tryReadChan" in
> Control.Concurrent.Chan (note that the isEmptyChan is not useful for
> making non-blocking read),
isEmptyChan is not useful for anything because it blocks when the channel is
empty and another thread calls readChan. The following code waits forever
after printing the "1":
test = do
c <- newChan
forkIO $ forever $ do
i <- readChan c
writeChan c 1
isEmptyChan c >>= print
ben at sarun: .../hca/current > ghci Bug5.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Bug5.hs, interpreted )
Ok, modules loaded: Main.
BTW, when I interrupt this with Ctrl-C, ghc-6.10.2 crashes with a
segmentation fault. With ghc-6.10.1 I get a clean "Interrupted" message and
a new prompt. This looks like a regression to me.
More information about the Glasgow-haskell-users