[MLton] Win32 Spawn's Seem Broken

[Brent Fulgham]

When I run my DOS MLton executable, I get this strange
behavior:

   Compile C and Assemble starting
      gcc -c -Ic:\mingw\lib\mlton\include -O1
-fno-strict-aliasing \
          -fomit-frame-pointer -w -fno-strength-reduce
-fschedule-insns \
          -fschedule-insns2 -malign-functions=5
-malign-jumps=2 \
          -malign-loops=2 -mcpu=pentiumpro -o
/tmp/fileNEFCzm.o \
          /tmp/filecLXTZK.1.c
About to wait on PID: 0
   Compile C and Assemble raised in 0.00 + 0.00 (0%
GC)
MLton raised in 0.00 + 0.00 (0% GC)
call to system failed with No error:
gcc -c -Ic:\mingw\lib\mlton\include -O1
-fno-strict-aliasing -fomit-frame-pointe
r -w -fno-strength-reduce -fschedule-insns
-fschedule-insns2 -malign-functions=5
 -malign-jumps=2 -malign-loops=2 -mcpu=pentiumpro -o
/tmp/fileNEFCzm.o /tmp/file
cLXTZK.1.c


Looking into the source, I see this:

fun spawne {path, args, env} =
  if isCygwin orelse isMingwin
    then
      let
        val path = NullString.nullTerm path
        val args = C.CSS.fromList args
        val env = C.CSS.fromList env
      in
        SysCall.syscall
          (fn () =>
            let val pid = Prim.spawne (path, args,
env)
            in (Pid.toInt pid, fn () => pid)
            end)
          end
       else
[ ... ]

This seems to think spawne returns a PID.

But, the spawn sources say:

result = spawnve(0, path, 
           (const char * const *)args,
           (const char * const *)env);

The flag '0' does not indicate asynchronous, so this
call actually blocks waiting for "path" to complete,
then it provides its return code (0 in this case).

We then attempt to waitpid for 0, which fails since
there is no such pid.

Should I:

1.  Modify spawnp/spawne to use "NON_BLOCK" so that it
returns a PID, rather than a return code?

-or-

2.  Modify the process.sml so that it doesn't do a
waitpid when spawning (since it will block).

-or-

3.  Modify waitpid so that a PID of zero does not seek
to find the PID, and ends successfully?  (HACK!)

Thoughts?

-Brent