[Haskell-cafe] ReaderT and concurrency

Andrew Pimlott 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
not sure.

> Besides,
> 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.

Andrew


More information about the Haskell-Cafe mailing list