[Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
alexander.kjeldaas at gmail.com
Wed Oct 17 13:10:08 CEST 2012
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
> > *all invariants hold*. Thus no locks held, no thread is in the C
> > 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe