On Tue, 16 Oct 2012 21:55:44 +0200 Alexander Kjeldaas <alexander.kjeld...@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 <m...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe