[MLton] interrupted system call

[Matthew Fluet]

> And finally, your point about limit check insertion.
>
> So, it looks like we have a bug, assuming we can concoct a scenario
> wher the loop header is inside a critical section but other parts of
> the loop aren't.

Seems pretty easy to do so.

> Another fix would be your suggestion
>
> > add a primitive that enters the runtime (and may switch threads)
> > which invokes the signal handler (respecting canHandle).  I can
> > imagine situations where I'd like an atomicEnd that not only left
> > the critical region, but immediately invoked the signal handler if a
> > signal were pending.
>
> It seems fine to me to always have atomicEnd do this.  That is,
> instead of
>
> if (gcState.signalIsPending and 0 == gcState.canHandle)
> 	gcState.limit = 0;
>
> Why not
>
> if (gcState.signalIsPending and 0 == gcState.canHandle)
> 	GC_gc (&gcState, ...);

That seems reasonable to me.

> If we do this, then we could tweak signal check insertion to know that
> blocks with atomicEnd automatically break loops.

That won't fall out automatically from the fact that atomicEnd get's
translated to a GC_gc?