[MLton-user] fork() in MLton on Cygwin

[Stephen Weeks]

> I want to use fork() in MLton on Cygwin and would like
> to know why it's disabled. I've seen reference to a
> "Cygwin fork/mmap bug" in
> basis-library/posix/process.sml. Is there a concrete
> example of this bug?

There were many such examples when I ported MLton to Cygwin two and a
half years ago.  During the port, I was constantly tracking down
problems thinking they were my bugs, only to find that Cygwin wasn't
emulating mmap correctly, sometimes even without fork, often when fork
was used.  Basically, the whole system was completely unreliable.  I
even submitted a bug report or two to the Cygwin team.  I found their
response lacking.

So, I disabled fork (and enabled spawn) and used the Win32 memory
management primitives.  With that, MLton reached close to the level of
reliability we see on other platforms.

> runtime/gc.c:
> removed #include <windows.h>
> replaced VirtualAlloc/VirtualFree (which aren't
> tracked by Cygwin) with mmap/munmap
> replaced showMem() with a stub version
..
> After trying to use a C fork() wrapper and debugging
> the binary with gdb, I discovered a few changes that
> allow fork() to work (at least superficially) on
> Cygwin. I got a simple program (it forks and prints
> from parent and child) to work after recompiling MLton
> with the following changes:
> 
> basis-library/posix/process.sml:
> removed the val fork = ..., so the fork syscall is
> always used (the old synchronization mechanism doesn't
> seem necessary)

This all make sense.  I remember the synchronization mechanism as one
of my attempts to work around their bugs.  Perhaps Cygwin's mmap
emulation has improved in the last couple of years.  You could try
running all the MLton regressions with your patch and see how they go.
If those work, I'll consider patching MLton so that we enable fork on
Cygwin for our next release.