[Haskell-cafe] ReaderT and concurrency
andrew at pimlott.net
Wed Nov 16 13:53:17 EST 2005
On Wed, Nov 16, 2005 at 07:20:48PM +0100, Tomasz Zielonka wrote:
> On Wed, Nov 16, 2005 at 09:45:17AM -0800, Andrew Pimlott wrote:
> > On Wed, Nov 16, 2005 at 11:51:19AM -0500, Kurt Hutchinson wrote:
> > > I have to perform another runReaderT when forking? Or is there a way
> > > to get the ReaderT environment automatically carried over to the newly
> > > created Set B thread?
> > This is an unavoidable pain as far as I know. It would be nice if
> > forkIO were defined in terms of MonadIO:
> > forkIO :: MonadIO m => m () -> m ThreadId
> > (Same with forkProcess.) I haven't thought too hard about it, but it
> > seems that it should be possible.
> I think it wouldn't be possible using only methods in MonadIO.
Here's what I had in mind for forkProcess. Recall that the fork syscall
returns 0 to the child and a pid to the parent.
forkProcess :: MonadIO m => m () -> m ProcessID
forkProcess io = do pid <- liftIO forkSyscall
if (pid == 0) then io >> exit
else return pid
But maybe the primitives used by forkIO do not allow this approach. I'm
> what should be the semantics of forkIO for (StateT s IO)? I can't think
> of anything reasonable.
I don't see the problem--they would each get a copy of the state.
Although I could be missing something, as I use System.Posix.Process
more than Control.Concurrent.
More information about the Haskell-Cafe