[Haskell-cafe] Re: Bug in runInteractiveProcess?
Simon Marlow
simonmarhaskell at gmail.com
Wed Oct 17 04:56:21 EDT 2007
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
More information about the Haskell-Cafe
mailing list