On Thu, 13 May 2010, David Matthews wrote:
Makarius wrote:
On Linux on the same hardware class the result is like that:
ML elapsed_time (fn () = join (fork true)) ();
0.102
These 100ms are somehow intrinsic to the way the Poly/ML runtime system
invokes external processes. David can
Makarius wrote:
On Wed, 12 May 2010, Michael Norrish wrote:
Cygwin is not really relevant, but I suppose that, out of idle
curiosity, it would nice to know if Posix.Process.exec worked there.
I have checked the (long) mail exchange with David from 2 years ago,
when we sorted out many issues
Michael Norrish wrote:
Well, it seems as if the problem for exec is just on MacOS, and I'm
happy to fork there, even if it's annoying to have to do so. Cygwin is
not really relevant, but I suppose that, out of idle curiosity, it would
nice to know if Posix.Process.exec worked there. My
On Wed, 12 May 2010, Michael Norrish wrote:
Cygwin is not really relevant, but I suppose that, out of idle
curiosity, it would nice to know if Posix.Process.exec worked there.
I have checked the (long) mail exchange with David from 2 years ago, when
we sorted out many issues to make it work
On Tue, 11 May 2010, David Matthews wrote:
Michael Norrish wrote:
Incidentally, on the machine where Posix.Process.exec(/bin/ls, []) seg.
faults, Unix.execute(/bin/ls, []) works correctly. The Basis library
documentation I have for the Unix structure doesn't discuss how the argv
component
In the above code the invoker will return immediately with success. It
ought to be possible to modify the code to use Posix.Process.waitpid to
wait for the child process. Possibly something along the lines of
SOME pid =
(case Posix.Process.waitpid(Posix.Process.W_CHILD pid, []) of
W_EXITED =
I tried this out under the debugger and found it was actually ls
itself that was crashing. I suspect the reason for the difference in
behaviour has to do with differences in the implementation of /bin/ls
on different platforms. When calling Posix.Process.exec you have to pass
all the arguments
