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

[Dean Herington]

George Russell wrote:

> Dean Herington wrote:
> >
> > George Russell wrote:
> >
> > > > > Posix.runProcess really should use it I think.
> > > >
> > > Volker Stolz wrote:
> > > > 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.
> Er, are you confusing Posix.forkProcess (which I was talking about) with Posix.runProcess (which
> is what I am talking about now)?

Sorry for confusing them.  I agree with you that, for Posix.runProcess, auxiliary threads should not
be allowed to continue in the child process.  In fact, I had to abandon use of Posix.runProcess in
my application because it (currently) allows those threads to continue.  A second reason
Posix.runProcess didn't do the job for me is that it doesn't return a handle to the child process,
as you also pointed out.

Concerning forking a process (without necessarily doing exec), I agree with Volker that an option to
control retention or deletion of auxiliary threads is desirable.

Dean