Why it's dangerous to fork off a new process in Glasgow Haskell

[Dean Herington]

George Russell wrote:

> > > Posix.runProcess really should use it I think.
> >
> > No, it's better to be able to choose the way to handle this.
> > Maybe add a flag to Posix.runProcess. But the whole
> > GHC.Conc.forkProcess isn't finished, yet, anyway.
> I don't really see the point of allowing the user to choose the old way.
> Posix.runProcess is supposed to fork off a new process outside of this
> runtime system.  I don't see any way this can be helped by allowing other
> threads to continue in the child until the actual time of exec, unless for
> some reason the evaluation of the arguments to exec somehow relies on other
> threads.  But this would surely at least require argument evaluation to
> unsafely conceal IO, and in any case could be better fixed by forcing the
> arguments to be fully evaluated before the fork.

Let's not forget that the new (child) process may never do exec().  I have an interpreter that
forks to replicate itself, relying on the runtime system to carry over.

My application uses multiple (GHC) threads as well as multiple (Unix) processes.  I use an
MVar to mutually exclude operations that are externally visible, so that in a new child
process I can kill preexisting auxiliary threads.  In my case, the cost in coding is modest;
I'm not yet at the point where I can gauge the execution cost.  The version of `forkProcess`
that doesn't retain preexisting auxiliary threads is attractive, except that those threads are
apparently not (currently) garbage collected properly in the child process.

In my experience, I've not found a use for retaining auxiliary threads in the child process
after a fork.  On the other hand, I'm not yet convinced that couldn't be useful in some
application.

Dean