[MLton] Finished (?) MLton.Child

[Wesley W. Terpstra]

On Wed, Nov 24, 2004 at 09:14:13PM -0800, Stephen Weeks wrote:
> But, I'm not convinced it's worth pursuing.  One can use
> Cygwin+fork/mmap or MinGW+CreateProcess/VirtualAlloc.  I don't see the
> need for pushing hard to make Cygwin+CreateProcess/VirtualAlloc work.

I don't either; cygwin is an attempt to be UNIX-like.
Respect its wishes. ;) OTOH, uniformity is important.

Also, I now think it should be possible (when I started I didn't).
The method get_osfhandle (no _) is present in io.h.
The lack of _ suggests to me that it is a cygwin filedes compatible method.

That means it might work with filedescs from cygwin's pipe()!
Therefore, if dupHandle used this, CreateProcess+cygwin would probably
work. There would just need to be TerminateProcess and _cwait exposed.

One simple way to do this would be to make methods 
	MLton_Process_Terminate -> TerminateProcess and
	MLton_Process_cwait -> _cwait

Alias those to kill() and waitpid() under mingw.
In cygwin leave kill and waitpid pointing to cygwin.dll.

Then, in process.sml, use MLton_Process_Terminate and MLton_Process_cwait
instead of kill and waitpid when useCreateProcess is true.

I'd give that 50/50 odds of working.
There would still be the path translation issue, but
cygwin_conv_to_full_win32_path appears to be the ticket.

If it does work, it would probably be better to use this than fork+exec.
After all, fork internally does a CP and then a whole bunch of other, more
failure prone stuff. Just using the CP would probably be faster and safer.

However, I still think cygwin should support fork() for other apps.

> ... but, if you want, feel free to investigate.

I will; it would be nice if Unix.* worked on every MLton platform.
High-level languages should strive to provide platform uniformity IMO.

Speaking of which, if I write Windows : WINDOWS (in the distant future), 
I would have to create /etc/registry and ~/.registry. ;) muahaha!

> > > static HANDLE dupHandle (int fd) {
> > >        HANDLE raw, dupd;
> > >
> > >        raw = (HANDLE)_get_osfhandle (fd);
> > 
> > cygwin.c:
> > > #include "create.c"
> > 
> > !? How does this compile? I see no definition for _get_osfhandle in cygwin.
> > There's a get_osfhandle in io.h, but where is _get_osfhandle?
> 
> Dunno.  This was part of my attempt to make Cygwin+CreateProcess
> work.  I figured since _get_osfhandle worked on MinGW, it would work
> here.  I did have to add a prototype in Cygwin.h though.

Hrm. I don't like using methods not declared in headers unless I have the
source code for the thing I'm calling into. :) get_osfhandle is probably
more likely to cooperate with the cygwin file descriptors.

I was using setmode always under cygwin and _setmode always under mingw.
My reasoning: cygwin has it's own file descriptors, and the lack of _
suggests that the method has be cygwin-ized to be safe with them.
Mingw uses the windows c-runtime dll so using the windows file descriptor
table is the correct thing to do: hence _setmode (as documented at msdn).

> I've also now fixed the (stupid) bug with use-mmap.  The test now
> works perfectly.  SML test code below.

You mean that cygwin+fork works for you now? (no more hang?)
Good good. I will just put a few hours effort into fixing cygwin+CP then.

-- 
Wesley W. Terpstra