On Wed, 2008-09-03 at 10:33 +0200, Robert Jordan wrote: > Avery Pennarun wrote: > > However, I don't understand the rationale here. It seems to me that > > fork() has nothing to do with shutdown, and thus cannot possibly > > bypass "essential shutdown code." On the other hand, Syscall.execve > > is *not* obsolete and *does* bypass shutdown code. Furthermore, the > > recommended System.Diagnostics.Process class provides no equivalent to > > fork(), so I'm not sure why it's being recommended. > > > > What's the rationale here? > > If a child is calling exit() upon termination, parent's handles will > be closed as well. This will most likely break parts of the runtime > (io-layer, etc.). > > execve is different because it simply replace the process, thus it > can `only' break code that depends upon a clean shutdown.
The other issue with calling fork() is that, to quote an ancient IRC discussion: < lupus> fork is tricky and likely won't work < lupus> anything can happen: the child process is not setup to execute mono code < lupus> an immediate exec may or may not work Alas, I didn't get any further details, but that was enough for me to remove fork() from Syscall: if it can't ever be reliably called, then it shouldn't be callable. My guess is that since Mono is multithreaded, and locks/etc. are required to generate JITed code, it's possible that "during" your fork() call another thread is busy JITing away, holding the JIT lock, and after the fork() call the new process will have only a single thread, and those locks would still be "held" (even though there's no thread holding the locks in the new process), resulting in deadlock when you try to JIT the Syscall.exec() call. This would be Bad, and decidedly non-trivial to debug should this ever happen. - Jon _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list