[Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

[Mike Meyer]

On Tue, 16 Oct 2012 21:55:44 +0200
Alexander Kjeldaas <alexander.kjeldaas at gmail.com> wrote:

> There are variants of this, but the meta-problem is that at the point in
> time when you call forkProcess, you must control all threads, ensuring that
> *all invariants hold*.  Thus no locks held, no thread is in the C library,
> no foreign calls active etc.  As an example, if one thread is in the C
> library doing some stdio, then the invariants in that library will not
> hold, and you cannot expect stdio to work in the child.  This means that
> the only thing you can really do in the child process is call exec.

Further, you can only call exec if you make sure that the exec
correctly reverts everything back to a state where those invariants
hold. Mostly, this is automatic as resources get freed on exec and "do
the right thing." Locks on file descriptors that aren't closed on exec
will leave dangling locks, and locks on files that are closed on exec
will unexpectedly close them in the parent.

   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org