the last bug

[Stephen Weeks]

I am now working on "the last bug" before the release.  Here is the problem.  If
we are in both a critical section and have a signal pending, then we obviously
do not want to run the signal handler since it might switch threads.  Right now,
whenever there is a signal pending, then limit == base so that the next limit
check will fail and we will enter the runtime.  In the problematic case above,
the runtime observes that we are in a critical section, does nothing, and
returns in the same state, where limit == base.  So, the limit check loop (see
the LimitCheck macro in ccodegen.h) decides that the gc didn't get enough space,
calls the gc again, and we loop forever.

My proposed solution is to change the setup so that whenever we enter the
problematic state, either by receiving a signal while in a critical section or
entering a critical section while a signal is pending, we do *not* set limit ==
base, because we know it will do us no good to enter the GC to handle the
signal.

This change means that GC_handler, Thread_atomicBegin, Thread_atomicEnd become
slightly more complicated, but does not require any codegen changes.

I also claim that this means that line 1160 of gc.c can be changed from
	} else if (0 == s->canHandle) {
to
	} else {
		assert (0 == s->canHandle);

That is, we know that if we enter the gc and didn't need to gc the heap or
resize the stack, then we must be handling a signal.

Any thoughts?