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

[Avery Pennarun]

On Wed, Sep 3, 2008 at 9:30 AM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> On Wed, 2008-09-03 at 10:33 +0200, Robert Jordan wrote:
>> 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 [...]

Hmm, I see the point.  From someone's spec for fork()
(http://www.opengroup.org/onlinepubs/000095399/functions/fork.html):

    A process shall be created with a single thread. If a
multi-threaded process calls fork(), the
    new process shall contain a replica of the calling thread and its
entire address space, possibly
    including the states of mutexes and other resources. Consequently,
to avoid errors, the child
    process may only execute async-signal-safe operations until such
time as one of the exec
    functions is called.

So, yeah.  On the one hand, since fork-then-exec *is* a valid thing to
want to do, and execve is available, and execve is almost (thought not
quite) entirely useless without being able to also fork(), it seems
like maybe fork() should still be available.  On the other hand, I
wouldn't have read the documentation and found out that my use case
wasn't recommended, because I felt I already knew what fork() is
supposed to do, so I see your point in removing it :)

So my next question then is: is there any way to get mono to *not* use
threads unless you explicitly ask it to do so?  It seems like just the
GC and JIT are threads right now, right?  Actually I don't know enough
to even describe why the JIT would want to be a thread anyway...

An optionally-threadless mono runtime would be a great way to get us
one step closer to being able to write real system apps, which sadly
must sometimes use fork().

Thanks for clarifying, though.  I'll have to find a better alternative.

Have fun,

Avery