ioref

Forked IORef reader function seems to stall main thread

由 最后都变了- 提交于 2019-12-23 12:24:09
问题 I was doing some experiments with concurrency and memory visibility and ran into this strange behavior (see comments inline): module Main where import Data.IORef import Control.Concurrent import System.CPUTime import System.IO main = do hSetBuffering stdout NoBuffering r <- newIORef False putStrLn "forking..." -- PRINTED forkIO $ f r threadDelay 1000000 putStrLn "writeIORef" -- NEVER PRINTED writeIORef r True threadDelay maxBound f :: IORef Bool -> IO () f r = readIORef r >>= \b-> if b then

Confusion over IORefs to make a counter

由 China☆狼群 提交于 2019-12-21 19:50:14
问题 I found some sample code, and changed it a little counter = unsafePerform $ newIORef 0 newNode _ = unsafePerformIO $ do i <- readIORef counter writeIORef counter (i+1) return i Which returns 1 then 2 then 3 then 3 etc each time it's run. But when I change it to newNode = unsafePerformIO $ do i <- readIORef counter writeIORef counter (i+1) return i then I get 0 every time I run it. Why is this happening, and what can I do to fix it? 回答1: In your second version newNode is a simple value, not a

Avoiding IORefs in pure code

由 萝らか妹 提交于 2019-12-20 11:12:41
问题 I noticed that Data.UnionFind uses the IO monad to provide pointers via IORefs. I imagine everyone happily calls unsafePerformIO when using it locally in pure code, since the data structure is so well understood, but .. Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO operations? 回答1: Is there a canonical cleaner approach to such data structures? Perhaps a wrapper

Avoiding IORefs in pure code

由 邮差的信 提交于 2019-12-20 11:12:36
问题 I noticed that Data.UnionFind uses the IO monad to provide pointers via IORefs. I imagine everyone happily calls unsafePerformIO when using it locally in pure code, since the data structure is so well understood, but .. Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO operations? 回答1: Is there a canonical cleaner approach to such data structures? Perhaps a wrapper

Haskell: performance of IORefs

由 ε祈祈猫儿з 提交于 2019-12-12 07:53:12
问题 I have been trying to encode an algorithm in Haskell that requires using lots of mutable references, but it is (perhaps not surprisingly) very slow in comparison to purely lazy code. Consider a very simple example: module Main where import Data.IORef import Control.Monad import Control.Monad.Identity list :: [Int] list = [1..10^6] main1 = mapM newIORef list >>= mapM readIORef >>= print main2 = print $ map runIdentity $ map Identity list Running GHC 7.8.2 on my machine, main1 takes 1.2s and

Haskell: generic IORef, MVar?

由 寵の児 提交于 2019-12-04 22:30:04
问题 I made the following function which is specific for the IO monad: memoIO :: MonadIO m => m a -> IO (m a) memoIO action = do ref <- newMVar Nothing return $ do x <- maybe action return =<< liftIO (takeMVar ref) liftIO . putMVar ref $ Just x return x Example usage: main :: IO () main = do p <- memoIO $ putStrLn "hello" p p Prints " hello " once. I would like (a pet peeve) to make it work for as many cases as possible (not just in IO). I found stateref on hackage and with it my code looks like

Confusion over IORefs to make a counter

由 半腔热情 提交于 2019-12-04 09:01:59
I found some sample code, and changed it a little counter = unsafePerform $ newIORef 0 newNode _ = unsafePerformIO $ do i <- readIORef counter writeIORef counter (i+1) return i Which returns 1 then 2 then 3 then 3 etc each time it's run. But when I change it to newNode = unsafePerformIO $ do i <- readIORef counter writeIORef counter (i+1) return i then I get 0 every time I run it. Why is this happening, and what can I do to fix it? In your second version newNode is a simple value, not a function. So haskell evaluates it exactly once and then gives you the result of that evaluation whenever you

When to use STRef or IORef?

由 不打扰是莪最后的温柔 提交于 2019-12-04 00:02:32
What exactly is the difference between STRef and IORef and when do I use each of them? As far as I can tell they both are for mutable state so whats the point of both of them existing? You can do more things in the IO monad than in the ST monad. The latter provides mutable references, the former provides mutable references, exception catching, threads, and of course IO. It is usually good Haskell practice to use the "weakest" or "more restricted" tool available that can solve your problem, because "weaker" tools tend to be easier to understand and analyze (another place this principle crops up

When is it OK to use an IORef?

由 泄露秘密 提交于 2019-12-03 02:08:22
问题 One thing that has always confused me is whether or not it's an okay time to use an IORef. Are there any guidelines that should be followed when deciding whether or not to use an IORef for a task? When is a good time to use the State monad over an IORef? 回答1: State and its relative ST both produce `monolithic' stateful computations which may be run as units. They basically treat the mutable state as intermediate data, which is needed to produce a result, but should not, in and of itself, be

Avoiding IORefs in pure code

由 僤鯓⒐⒋嵵緔 提交于 2019-12-03 01:18:29
I noticed that Data.UnionFind uses the IO monad to provide pointers via IORefs. I imagine everyone happily calls unsafePerformIO when using it locally in pure code, since the data structure is so well understood, but .. Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO operations? Don Stewart Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO
订阅 ioref