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