[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