threads are the bug

[Stephen Weeks]

> 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.

OK.  I now have the following in gc.h

	volatile int canHandle;
	volatile bool signalIsPending;

> 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.

I don't think this is a problem, given that the signalIsPending stuff works
right.  The point is that once Thread_atomicBegin has incremented canHandle, then
GC_handler will never set limit.  So the only possible conflict is if the
signal happens before the increment.  With both canHandle and signalIsPending
declared volatile, we are guaranteed that in that case the setLimit in
Thread_atomicBegin will override the limit assignment in GC_handler.

> ALL OF THIS SUCKS.  Why are we suffering  this  horrible  thread  world.   It
> isn't  worth  it. 

I agree this is horrible.  But, I think we do need threads.  Also, some of this
mess comes from supporting signals, which we need even more than threads.  And,
I want to play around with CML at some point -- I think it may be a reasonable
high-level thread model.  Once we get this low-level stuff right, we can play
around with higher level thread concepts without worrying about this low-level
stuff.

> If you feel it is needed, just have another flag and check
> that in addition. 

I think the signalIsPending flag serves this purpose.

> I object though to the slow down.   The  thread  thing  is
> silly.

I don't see any slowdown for programs that don't use signals or threads.