On 17 October 2012 00:17, Mike Meyer <[email protected]> wrote: > On Tue, 16 Oct 2012 21:55:44 +0200 > Alexander Kjeldaas <[email protected]> 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 <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
