[Haskell-cafe] Re: Bug in runInteractiveProcess?

[Simon Marlow]

John Goerzen wrote:
> On 2007-10-17, Simon Marlow <simonmarhaskell at gmail.com> wrote:
>> 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.
> 
> That would be most annoying, and would render HSH unable to function
> without using FFI to import fork from C.  I suspect that forkProcess has
> some more intelligence to it than that, though I haven't looked.
> 
> System.Process is not powerful enough to do serious work on POSIX, and
> perhaps it never can be.  The mechanism for setting up a direct pipeline
> with more than 2 processes is extremely inconvenient at best, and it
> does not seem possible to create n-process pipelines using
> System.Process without having to resort to copying data in the Haskell
> process at some point.  (This even putting aside the instant bug)
> 
> Not only that, but the ProcessHandle system doesn't:
> 
>  * Let me get the child process's PID
>  * Send arbitrary signals to the child process
>  * Handle SIGCHLD in a custom and sane way
>  * Get full exit status information (stopped by a particular signal,
>    etc)
> 
> Now, there are likely perfectly valid cross-platform reasons that it
> doesn't do this.

Yes, absolutely.

Although I *would* like there to be a more general version of 
runInteractiveProcess where for each FD the caller can choose whether to 
supply an existing Handle or to have a new pipe generated.  This would let 
you pipe multiple processes together directly, which can't be done at the 
moment (we've discussed this before, I think).

> I am merely trying to point out that removing
> forkProcess in favor of System.Process will shut out a large number of
> very useful things.

I wasn't intending to push users towards System.Process instead, rather to 
forking in C where it can be done safely.  I completely agree that 
System.Process isn't a replacement for everything you might want to do with 
fork.

> Don't forget either that there are a whole class of programs whose
> multithreading needs may be better addressed by forkProcess,
> executeFile, and clever management of subprograms rather than by a
> threaded RTS.

Ok, the non-threaded RTS can indeed support forkProcess without any 
difficulties.  I'm not sure where that leaves us; the non-threaded RTS also 
cannot support waitForProcess in a multithreaded Haskell program, and it 
can't do non-blocking FFI calls in general.

While we have no immediate plans to get rid of the non-threaded RTS, I'd 
really like to.  The main reasons being that it adds another testing 
dimension, and it contains a completely separate implementation of 
non-blocking IO that we have to maintain.

> forkProcess, with the ability to dupTo, closeFd, and executeFile is
> still mighty useful in my book.

Noted!

Cheers,
	Simon