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@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