GHC threading bug in QSem

[Ben Franksen]

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":

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

test = do
  c <- newChan
  forkIO $ forever $ do
    i <- readChan c
    print i
  writeChan c 1
  threadDelay 1000000
  isEmptyChan c >>= print

Test session:

ben at sarun[1]: .../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.
*Main> test
1

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.

Cheers
Ben