On Wed, Nov 16, 2005 at 10:53:17AM -0800, Andrew Pimlott wrote: > On Wed, Nov 16, 2005 at 07:20:48PM +0100, Tomasz Zielonka wrote: > > 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
Well, yes, I haven't thought about it. I don't know forkSyscall and I can't say if it's a good idea or not. > But maybe the primitives used by forkIO do not allow this approach. I'm > not sure. I'm pretty sure they don't, but I may be wrong again. They could probably be extended to allow this. However, I'm not sure I would like this, because it would be too easy to break abstraction. > > 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. Yes, but the changes made in the child thread would be ignored in the parent. Best regards Tomasz _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
