[Mono-dev] System.Unix.Native.Syscall.fork is commented out

[Jonathan Pryor]

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