John Goerzen wrote:
On 2007-10-17, Simon Marlow <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
