threads are the bug

[Henry Cejtin]

The rule is that if you don't declare a variable volatile, then if a function
looks at it and then grinds for a while, and then looks at it again,  it  can
assume  that it didn't change during the grinding.  Typically if the grinding
involves a function call, the assumption will not be made because C compilers
don't  do  much inter-procedure analysis.  You definitely do NOT want gcState
to be volatile.  That  will  cost  infinity.   What  you  want  is  for  just
gcState.signalIsPending  to  be  volatile.  It isn't clear to me that this is
enough.  setLimit writes to the limit member, reading base and fromSize.  The
signal  handler  writes  to  limit.   Thus either one can win if an interrupt
happens while the code is in Thread_atomicBegin.

ALL OF THIS SUCKS.  Why are we suffering  this  horrible  thread  world.   It
isn't  worth  it.  If you feel it is needed, just have another flag and check
that in addition.  I object though to the slow down.   The  thread  thing  is
silly.