ioref | 易学教程

Forked IORef reader function seems to stall main thread

阅读更多关于 Forked IORef reader function seems to stall main thread

问题 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

阅读更多关于 Confusion over IORefs to make a counter

问题 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

阅读更多关于 Avoiding IORefs in pure code

问题 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

阅读更多关于 Avoiding IORefs in pure code

Haskell: performance of IORefs

阅读更多关于 Haskell: performance of IORefs

问题 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?

阅读更多关于 Haskell: generic IORef, MVar?

问题 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

阅读更多关于 Confusion over IORefs to make a counter

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?

阅读更多关于 When to use STRef or IORef?

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?

阅读更多关于 When is it OK to use an IORef?

问题 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

阅读更多关于 Avoiding IORefs in pure code

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