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: b...@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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users