Donn Cave wrote:
On Oct 16, 2007, at 1:48 PM, John Goerzen wrote:
I have been trying to implement a Haskell-like version of shell pipelines using runInteractiveProcess. I am essentially using hGetContents to grab the output from one command, and passing that to (forkIO $ hPutStr) to write to the next. Slow, but this is just an experiment.
As an aside, I personally would look to System.Posix.Process for this. Something like this would deal with the file descriptors in the fork ...
fdfork fn dupfds closefds = do pid <- forkProcess $ execio return pid where dupe (a, b) = do dupTo a b closeFd a execio = do mapM_ dupe dupfds mapM_ closeFd closefds fn
Note that forkProcess doesn't currently work with +RTS -N2 (or any value larger than 1), and it isn't likely to in the future. I suspect forkProcess should be deprecated. The POSIX spec is pretty strict about what system calls you can make in the child process of a fork in a multithreaded program, and those same restrictions apply in Haskell, and they apply not only to the Haskell code but also to the runtime (e.g. what if the child process needs more memory and the runtime calls mmap(), that's not allowed). We get away with it most of the time because the OSs we run on are less strict than POSIX. However, in general I think forking should be restricted to C code that you invoke via the FFI. Cheers, Simon