[MLton] interrupted system call

[Stephen Weeks]

>      + Another alternative would be to make this behavior a compile time
>        decision.  On argument against doing so is that sigaction
>        determines this behavior dynamically, by the SA_RESTART flag, so
>        it should be dynamic here as well. 

Yeah, dynamicallly deciding Signal.restart seems better.

>     + the translation of atomicEnd can actually be predicated upon
>       handlesSignals.  We are keeping the canHandle inc and dec because
>       it's useful for asserts.  But, there is no need to put in a GC safe
>       point if signals aren't being handled.

I had forgotten that's the only reason we keep the inc and dec.  Maybe
this would be a good time to fix that.  We could make them no-ops if
the the program doesn't handle signals, keep a flag in gcState, and
fix any asserts to be "not s->handlesSignals orelse ...".

>     + We ought to verify that limit check uses GC_gc to decycle loops;

I just looked and see that both limit-check.fun and signal-check.fun
decycle at GC_gc.

>       however, this doesn't really matter.  atomicEnd gets translated
>       into a branch, with GC_gc down only one.  So the restart loop
>       remains unbroken by GC_gc.

Ah, right, we're relying on the behavior of atomicEnd, not
signal-check insertion.

> Have I missed anything?

Looks great to me.