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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe