[Haskell-cafe] Re: exitFailure under forkProcess

[John Goerzen]

On 2004-10-27, Glynn Clements <glynn at gclements.plus.com> wrote:
> 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.

This is not a novel problem with Haskell, but it certainly bears
remembering.

> 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).

And this *is* a novel problem I hadn't thought of before.  It's quite
possible this has been causing some of my troubles.

I would think that createProcess should automatically flush all open
handles before it does the fork, and that it should probably be
considered a bug if it doesn't.  If it does, then the exec stuff should
too.  If it doesn't, then the exec stuff must not.  (If the exec stuff
did but forkProcess didn't, it would break the idiom of fork() then
exec() that happens to work now because the exec() discards all those
buffers.)

I wonder what the behavior of fwrite() in this situation is.  I don't
know if it ever performs buffering such that write() is never called
during a call to fwrite().

I also wonder if the forkIO and friends suffer from the same problem.

> 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.

Yup.

-- John