[MLton] cvs commit: restructure of signal handling

[Stephen Weeks]

> >   The enter/leave functions of gc.c are also modified to treat runtime
> >   functions as running in a critical section (i.e., with canHandle++ in
> >   enter and canHandle-- in leave); this prevents limit from being
> >   modified while in the runtime.  If a signal is caught on the C side
> >   while in the GC, the limit will be reset to 0 during leave.
> 
> 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.

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;