MState: A consistent State monad for concurrent applications
Hi, I have been trying to use the State monad for concurrent applications and came up with a little library.[1] My "MState" uses an IORef to maintain the state between different threads. The library also offers a simple way to fork off new threads using its own "forkM" function. This function will asure that every thread in an "evalMState"/"execMState" call will be finished before the final result is returned. The library is also on github.com.[2] Please let me know what you think of it and whether or not I should put it on hackage. Cheers, Nils Schweinsberg [1] http://n-sch.de/hdocs/mstate/Control-Concurrent-MState.html [2] http://github.com/mcmaniac/mstate
On Fri, Jul 2, 2010 at 9:21 AM, Nils Schweinsberg
Hi,
I have been trying to use the State monad for concurrent applications and came up with a little library.[1] My "MState" uses an IORef to maintain the state between different threads. The library also offers a simple way to fork off new threads using its own "forkM" function. This function will asure that every thread in an "evalMState"/"execMState" call will be finished before the final result is returned.
The library is also on github.com.[2] Please let me know what you think of it and whether or not I should put it on hackage.
My thoughts on hackage: * For Haskell, if it's not on Hackage it doesn't exist :) * It's usually better to put it up on Hackage where someone will use it and then keep refining it as needed. In other words, don't be shy! Jason
On 02.07.2010 20:05, Jason Dagit wrote:
In other words, don't be shy!
Ok, thanks for the reply! :) However, a question about haddock: evalMState :: Forkable m => MState t m a -- ^ Action to evaluate -> t -- ^ Initial state value -> m a This (and run-/execMState) gets rendered incorrectly. "Action to evaluate" is completly lost and "Initial state value" has moved one upwards to the "MState t m a". Is that a haddock bug or my fault?
On Friday 02 July 2010 22:32:37, Nils Schweinsberg wrote:
On 02.07.2010 20:05, Jason Dagit wrote:
In other words, don't be shy!
Ok, thanks for the reply! :) However, a question about haddock:
evalMState :: Forkable m => MState t m a -- ^ Action to evaluate -> t -- ^ Initial state value -> m a
This (and run-/execMState) gets rendered incorrectly. "Action to evaluate" is completly lost and "Initial state value" has moved one upwards to the "MState t m a". Is that a haddock bug or my fault?
Probably Haddock's fault. It had that bug for a while.
And here wo go. MState on hackage: http://hackage.haskell.org/package/mstate My first hackage library. :)
On Fri, Jul 2, 2010 at 4:59 PM, Nils Schweinsberg
And here wo go. MState on hackage:
http://hackage.haskell.org/package/mstate
My first hackage library. :)
Awesome. I needed something like that once, too, down to the same type signature for the fork function. Here's an instance from my code: instance MonadFork (ReaderT s IO) where fork newT = ask >>= liftIO . forkIO . runReaderT newT since you seem to be using mtl, feel free to integrate it in some form if you like, small though it is. ReaderT over concurrent primitives is nice because forking is just that easy. I just used MVars for my state monad; yours is better (more sophisticated). Cheers, Matt
On 03.07.2010 03:27, Matthew Gruen wrote:
Awesome. I needed something like that once, too, down to the same type signature for the fork function. Here's an instance from my code:
instance MonadFork (ReaderT s IO) where fork newT = ask>>= liftIO . forkIO . runReaderT newT
I've added this instance to the Forkable class and a few other instances to the MState (Fix, Reader, Writer, Cont and Error). I hope they're all correct. Thanks!
Daniel Fischer
On Friday 02 July 2010 22:32:37, Nils Schweinsberg wrote:
On 02.07.2010 20:05, Jason Dagit wrote:
In other words, don't be shy!
Ok, thanks for the reply! :) However, a question about haddock:
evalMState :: Forkable m => MState t m a -- ^ Action to evaluate -> t -- ^ Initial state value -> m a
This (and run-/execMState) gets rendered incorrectly. "Action to evaluate" is completly lost and "Initial state value" has moved one upwards to the "MState t m a". Is that a haddock bug or my fault?
Probably Haddock's fault. It had that bug for a while.
It's been fixed in the 2.7 release apparently (I haven't upgraded, so I haven't checked that myself). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Saturday 03 July 2010 00:52:00, Ivan Lazar Miljenovic wrote:
It's been fixed in the 2.7 release apparently (I haven't upgraded, so I haven't checked that myself).
Speaking of which, haddock-2.7.* came with 6.12.1, I believe, but from 6.12.2 on, haddock's version number was back down to 2.6.1? Anyway, it's also fixed in 2.6.1 (at least those which came with 6.12.2 or 6.12.3).
Daniel Fischer
On Saturday 03 July 2010 00:52:00, Ivan Lazar Miljenovic wrote:
It's been fixed in the 2.7 release apparently (I haven't upgraded, so I haven't checked that myself).
Speaking of which, haddock-2.7.* came with 6.12.1, I believe, but from 6.12.2 on, haddock's version number was back down to 2.6.1? Anyway, it's also fixed in 2.6.1 (at least those which came with 6.12.2 or 6.12.3).
No, 2.7 came out after 6.12.1 was released. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Saturday 03 July 2010 01:36:11, Ivan Lazar Miljenovic wrote:
No, 2.7 came out after 6.12.1 was released.
Yes, right. I had installed 2.7 on its own (to see whether a bug displaying infix data constructors was fixed there) and misremembered. Still odd that GHC ships with 2.6 long after 2.7 is on hackage (not that I mind in the least, 2.6 is working fine).
Daniel Fischer
On Saturday 03 July 2010 01:36:11, Ivan Lazar Miljenovic wrote:
No, 2.7 came out after 6.12.1 was released.
Yes, right. I had installed 2.7 on its own (to see whether a bug displaying infix data constructors was fixed there) and misremembered. Still odd that GHC ships with 2.6 long after 2.7 is on hackage (not that I mind in the least, 2.6 is working fine).
I'm guessing it's because they didn't want to have major version bumps for any of its associated packages during a minor version bump. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (5)
-
Daniel Fischer -
Ivan Lazar Miljenovic -
Jason Dagit -
Matthew Gruen -
Nils Schweinsberg