Re: Functions for builtin operators (?)

2009-04-08 Thread Colin Paul Adams
Simon == Simon Peyton-Jones simo...@microsoft.com writes: Simon Nowhere. It's a name generated by GHC itself during Simon compilation. OK. Is there some way to recognise what the function is? The problem is with ESC/Haskell. I have managed to get the code integrated into the 6.11

GHC threading bug in QSem

2009-04-08 Thread Neil Mitchell
Hi I believe the following program should always print 100: import Data.IORef import Control.Concurrent main = do sem - newQSem (-99) r - newIORef 0 let incRef = atomicModifyIORef r (\a - (a+1,a)) sequence_ $ replicate 100 $ forkIO $ incRef signalQSem sem waitQSem sem v

Re: GHC threading bug in QSem

2009-04-08 Thread Chris Kuklewicz
The code assumes newQsem is never given a negative argument without ever documenting this fact. http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Concurrent-QSem.html#waitQSem change not only putMVar sem (0, blocked++[block]) to putMVar sem (avail,

RE: Functions for builtin operators (?)

2009-04-08 Thread Simon Peyton-Jones
Nowhere. It's a name generated by GHC itself during compilation. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Colin Paul Adams | Sent: 08 April 2009 10:33 | To:

Re: GHC threading bug in QSem

2009-04-08 Thread Neil Mitchell
I've now raised a ticket to track this issue: http://hackage.haskell.org/trac/ghc/ticket/3159 Thanks, Neil On Wed, Apr 8, 2009 at 11:26 AM, Neil Mitchell ndmitch...@gmail.com wrote: Hi I believe the following program should always print 100: import Data.IORef import Control.Concurrent

Functions for builtin operators (?)

2009-04-08 Thread Colin Paul Adams
Where is a function with a name like the following defined in the ghc source code? .Classes._ ( tpl_B6 ) I've tried searching for such names - all I can find is a comment referring to tpl_B2. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users

Re: GHC threading bug in QSem

2009-04-08 Thread 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