[Haskell-cafe] Re: Bug in runInteractiveProcess?
simonmarhaskell at gmail.com
Thu Oct 18 04:33:36 EDT 2007
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,
> Now, there are likely perfectly valid cross-platform reasons that it
> doesn't do this.
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
> 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.
More information about the Haskell-Cafe