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

[Alexander Kjeldaas]

On 17 October 2012 00:17, Mike Meyer <mwm at mired.org> wrote:

> 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.
>
>
Right.  It should be renamed mostlyUnsafeForkProcess, assuming the
multi-threaded RTS is "mostly" the default one.

Alexander


>    <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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121017/e737f0e0/attachment.htm>