some observations
(a) In the past we would call checkForInterrupts. One of the  
interesting things with that routine was that it used  
interruptCheckCounter
to modulate how often it was called. Thus in the bytecode
	longUnconditionalJump
		/* begin internalQuickCheckForInterrupts */
			if ((foo->interruptCheckCounter -= 1) <= 0)

We tried only to call checkForInterrupts every 1 millisecond or so by  
incrementing, decrementing interruptCheckCounter  to some large number.

See my note on the squeak mailing list 	
"VM tuning results and a question or two?" November 16, 1999 11:09:04  
PM PST (CA)

We would of course set that to a negative number if we wanted a more  
instant response.

However now the HydraCode promptly does a return from interp on each  
jump backwards at some unknown cost, I'd guess this affects looping to  
some interesting value?


(b) Buried in checkForInterrupts was code to thump TheTimerSemaphore  
when needed and to watch for millisecond clock rollover.

But now it seems the platform implementer is now require to build a  
pthread based routine to mange the next wakeup time, and or do  
something clever elsewhere to
watch when the millisecond clock rolls over and/or exceeds the next  
expected wakeup time.

However that implies each implementation will have the same behaviour,  
where as before it was magically handled by the VM and not requiring  
lots of independently written operating system timer magic.


As of now I don't have a workable vm since I need to implement this  
timer thread logic and one hopes that will solve the where we lockup  
the carbon event handler as something fails
to process the draw window request at window activation properly.


--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================