[MLton] cvs commit: restructure of signal handling

[Matthew Fluet]

> > Of course, since signals can be caught on the C side while in the runtime,
> > it only makes sense to reset the limit when not in the ML signal
> > handler.
>
> Isn't the ML handler always run in a critical section, so won't this
> happen without an explicit test?  That is, instead of
>
> 	unless (s->inSignalHandler) {
> 		if (s->canHandle == 1 and s->signalIsPending)
> 			s->limit = 0;
> 	}
> 	s->canHandle--;
>
> can't we do
>
> 	if (s->canHandle == 1 and s->signalIsPending)
> 		s->limit = 0;
> 	s->canHandle--;
>
> since if we're in a signal handler and inside the runtime we know that
> s->canHandle >= 2.

Agreed.


> Also, the order of those two statements looks wrong to me.  Looking at
> how atomicEnd is implemented in ssa-to-rssa, I see that we first do
> the decrement and then the test.  The way it stands now, it looks
> broken if a signal comes in between the test and the canHandle--.
> Shouldn't we do
>
> 	s->canHandle--;
> 	if (s->canHandle == 0 and s->signalIsPending)
> 		s->limit = 0;

Agreed.