MinGW compilation on Windows and proposed improvements

Hi,


I have been trying to compile MLton under MinGW/MSYS
on Windows, using the MLton binary package from version
20100608.

When compiling MLton20100608, there is a problem
with latex not being present. Is it possible
to build it without documentation or is there some
other recommended way of making a MinGW build from source?
The 20100608 binary release works great, but I
intend to apply patches to the source (see below).

When trying to compile MLton20130715 (still on
MinGW/MSYS on Windows), there is
an actual compilation error with MLton_strerror
being undefined during link (I see in the code
that there is something funky going on with
undefining and redefining stderror):

make -C runtime
make[3]: Entering directory `/v/MLton/mlton-20130715/runtime'
gcc -std=gnu99   -fno-common  -pedantic -Wall -Wextra -Wformat=2 
-Wswitch-default -Wswitch-enum -Wuninitialized -Winit-self 
-Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wshadow -Wpointer-arith 
-Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes 
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-noreturn 
-Wmissing-format-attribute -Wredundant-decls -Wnested-externs -m32 
-Wno-format -Wno-missing-format-attribute -I. -Iplatform 
-Wdisabled-optimization -O2 -fomit-frame-pointer -falign-loops=2 
-falign-jumps=2 -falign-functions=5 -o gen/gen-types gen/gen-types.c util.o
util.o:util.c:(.text+0x287): undefined reference to `MLton_strerror'
collect2: ld returned 1 exit status

Regarding building MLton20100608 from source,
there is occasionally (on some machines,
typically with older Linux distributions,
it seems?) a problem on Linux that
this call hangs forever (then I have to kill
e.g. a process called run.x86-linux to stop it;
CTRL+C on the shell won't work):

Creating constants file.
"/usr/local/anoq_installed/MLton/20100608/Linux/src/patched/mlton-20100608/build/bin/mlton" 

-target "self" -build-constants true >tmp.c

This is not a big problem for me though, since
I can either use the binary distribution or
upgrade the Linux distribution (if patching
and building from source is needed).


I would also like to propose some patches with
improvements. There is a small can of worms
regarding MLton.Process.{create|kill|reap}
that I would like to sort out first.

When looking at the implementation of the
function kill in basis-library/mlton/process.sml
one sees this code:

case !status of
   NONE =>
     let
       val () = killFn (pid, signal)
     in
       ignore (reap p)
     end
| SOME _ => ()

There are at least two problems in this.
Firstly, it means that kill calls reap.
I know that there is no mentioning of MLton.Process.kill
and Posix.Process.kill promising not to block:
http://www.mlton.org/MLtonProcess
http://www.standardml.org/Basis/posix-process.html
but it seems strongly implied for the POSIX kill in C:
http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html
and the POSIX kill in C surely does not block on Linux.
MLton.Process.reap and Posix.Process.waitpid, on the
other hand, both block, so calling reap as part of kill
seems like a bad idea wrt. kill's blocking behaviour.
Secondly, one cannot guarantee that a single kill
call is enough to actually kill a process if it is
very computationally intensive, as in my case. Hence
it would be necessary to call kill multiple times,
until the process is actually killed, which is
not possible if kill blocks due to calling reap.
Thirdly, kill actually only does anything, if
!status is not NONE, which seems to mean (in the
code) only if reap has not already been called
(not 100% sure if there are other cases as well).
I don't know if this is good or bad. At least,
I would strongly suggest removing the line:

ignore (reap p)

and replace it by just

()

(thus the let-expression could be removed,
if you prefer). Then it becomes possible
to actually kill a process and kill's
blocking behaviour is more as expected.

Now for determining whether a process has
actually been killed by MLton.Process.kill.
Firstly, in general, note that the SML basis
library seems to raise exceptions instead of using
return codes for Posix:
http://www.standardml.org/Basis/posix-error.html
In MLton, I have at least experienced that
MLton.Process.reap and Posix.Process.waitpid_nh
may raise exceptions, but it seems that
{Posix|MLton}.Process.kill do not.
POSIX' kill in C seems to return -1 if a child
process is not found (e.g. due to having been
killed) and so does waitpid with the WNHANG
flag (corresponding to Posix.Process.waitpid_nh).
So one possible comment is that maybe
{Posix|MLton}.Process.kill should raise
exceptions in this case? Then testing whether
a process has been killed would just be a
matter of continuously calling kill, until
it raises an exception.

In case kill is actually not supposed to
raise an exception, then an alternative
(and maybe better or more correct?) approach
would be to use waitpid_nh, in which case I
would need to be able to use it on processes
created with MLton.Process.create.
To be able to do that, the pid of the process
would be needed. A very small and simple
extension that allows this is to add the line:

val getPid = fn z => make #pid z

after the lines defining getStderr, getStdin and getStdout
in the file basis-library/mlton/process.sml and add the line:

val getPid:    ('stdin, 'stdout, 'stderr) t -> pid

in the corresponding process.sig file.
The type pid is compatible with Posix.Process.pid,
as needed (if this pid type was intended to be
opaque, it would be necessary to convert it to
Posix.Process.pid, but that's currently not necessary).

Then I can check by calling Posix.Process.waitpid_nh
and seeing if it raises an exception, to determine
whether the child process has actually been killed.
In POSIX in C, this corresponds to waitpid returning
-1 when given the WNOHANG flag. As suggested earlier,
maybe kill also ought to raise such an exception.
As an alternative, to avoid exposing the pid from
MLton.Process.create, an equivalent of waitpid_nh
could be made in MLton.Process.

Notice that it is not necessarily obvious
from documentation such as:
http://pubs.opengroup.org/onlinepubs/009695399/functions/waitpid.html
or
http://linux.die.net/man/2/waitpid
that waitpid fails with a return value (pid) of -1,
in case the pid is not found, but this (and kill
returning -1) seems to be the only way of testing this.

On MinGW, I would therefore like waitpid_nh (or
other suitable solution to achieve the above)
to work, as well as chmod. I can propose patches
for this, but I would prefer getting it to build
from source first. I think that what Mike proposes
here would be a solution for chmod (where I would go with
the flavour where STRICT_UGO_PERMISSIONS is defined):
http://stackoverflow.com/questions/592448/c-how-to-set-file-permissions-cross-platform
Using WaitForSingleObject seems to be the way to
support something like waitpid and waitpid_nh on Windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx

The above patches and suggestions apply
equally well to MLton versions 20100608 and 20130715,
since the code in question does not seem to have
changed between these versions.


Cheers,
Johnny Andersen
-- 
http://www.cex3d.net/inverse/ - 3D models from images automatically
http://www.hardcoreprocessing.com
http://www.anoq.net/music/ - creative instrumental electronic music

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk