[MLton] Re: [MLton-commit] r6699

[Wesley W. Terpstra]

On Wed, Jun 17, 2009 at 2:25 PM, Matthew Fluet<fluet at tti-c.org> wrote:
> It seems that there are multiple, independent(?) issues.  Certainly one is
> that a Cygwin program doesn't like to be started via CreateProcess with a
> non-NULL lpEnvironment argument; I can't find any documentation for this,
> but I can definitely demonstrate it with some short C programs.

... great. Is this a cygwin bug? This seems a pretty serious issue.

> The other issue is that I don't believe that the int/pid_t returned by
> spawn{,p}{,e} is "the same" as the LPROCESS_INFORMATION.hProcess returned by
> CreateProcess.  I don't believe that the old code really works when reaping
> child processes referenced by their spawn{,p}{,e} pid_t (whether or not they
> are cygwin processes).

I believe the reason this used to work is the same reason that you
outline below. MLton_Process_cwait was used only to match
CreateProcess calls. The cygwin waitpid was used to match calls to
spawn/fork. We had implicitly overloaded the C type, but due to the
uses being disjoint there was no problem.

> It turns out that the MLton.Process.create result doesn't actually provide a
> means to extract the process id, although MLton.Process.Child.getPid would
> be trivial.

I believe this was intentional.

At any rate, the solution seems clear except that lpEnvironment =>
cygwin implosion. One possible work-around would be to temporarily
change the calling process' environment before invoking CreateProcess.
I don't find anyone else reporting this problem on google, though. Are
you sure?