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

On 17 October 2012 00:17, Mike Meyer wrote:

On Tue, 16 Oct 2012 21:55:44 +0200 Alexander Kjeldaas 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

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe