[Haskell-cafe] Re: exitFailure under forkProcess

[Glynn Clements]

Simon Marlow wrote:

> > Yes.  Its POSIX interface is, uhm, weird.  I can't quite put my finger
> > on it, but things like setting up a pipe to a child process's stdin
> > just seem brittle and fragile with all sorts of weird errors.  I can
> > do this in my sleep in C, Perl, or Python but in Haskell I can barely
> > make it work when I'm fully conscious :-)
> 
> *laughs*
> 
> Is there anything concrete we can do?  The POSIX layer is supposed to be
> pretty minimal, so in theory most POSIX idioms should not be harder in
> Haskell, and hopefully should be easier.

Part of the problem is that you can't always consider the use of
individual POSIX functions in isolation. Things which are done
(possibly unknowingly) in one place might affect the way in which
other system calls behave.

One major issue is the way in which fork() has global consequences.

E.g. if a library has file descriptors for internal use, fork() will
duplicate them. If the library subsequently closes its copy of the
descriptor, but the inherited copy (which the child may not even know
exists) remains open, the file (socket, device, etc) will remain open.

Another example of this is the interaction between buffered streams
and descriptors. If a process forks while "unflushed" data remains in
a stream, the data may be written twice. This can be quite serious if
the stream corresponds to some form of control channel (i.e. a pipe or
socket communicating with another process).

Ultimately, the only real solution to such issues is to ensure that
any high-level functionality provides a sufficient level of
cooperation with lower-level code, e.g. allowing it to be
"synchronised", or at least shut down into a state such that it
doesn't interfere, ensuring that it doesn't hide "unnecessary" details
which may actually be necessary in more involved programs, etc.

-- 
Glynn Clements <glynn at gclements.plus.com>