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

Garbage Collection g4rb4g3c0ll3ct10n@yahoo.com
Mon, 12 Jul 2004 16:23:51 -0700 (PDT)


--- Stephen Weeks <sweeks@sweeks.com> wrote:
> You could try running all the MLton regressions with
your patch and see how they go.


Thanks for your reply. After changing gc.c and
process.sml, I found the following changes in the
regression suite:

echo.sml, signals.sml, suspend.sml:
Used to fail on fork(), now pass

socket.sml:
Used to fail on fork(), now fork() "works" but fails
when parent attempts Socket.connect()

textio.2.sml:
Doesn't use fork(), fails because of how read()
handles '\r'

world{1..5}.sml:
Used to fail on fork, now fork() "works" but fails
during exec()


I haven't debugged the world?.sml tests thoroughly,
but I have found that the following work:

-a program that forks and execs

-saving the world and then loading it from the shell
(./foo @MLton load-world /tmp/world --)

-a program that saves the world, forks and the parent
loads the saved world

-a program that saves the world, forks and the child
loads the saved world using a C wrapper for exec

So the problem seems to be specific to how save/load
and fork/exec interact.

Besides gc.c, is there any other place where Windows
functions might need to be replaced with Cygwin
functions? Is there anything special about
MLton.World.save that affects the virtual address
space?

Thanks.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail