>John M McIntosh <johnmci at smalltalkconsulting.com> is claimed by the 
>authorities to have written:
>
>>  However in testing 3.2.8b3 on the macintosh under os-x we found some
>>  cases where we could hang IE. This turned out to be an issue with
>>  squeak when it is idle. If there is only the idle loop process
>>  running, then it seems there isn't a new method being activated, nor
>>  a long unconditional jump taking place. Thus the termination flag
>>  never is checked.
>This is very disturbing John. The idle loop bytecodes clearly include an
>A3 F8 longjump of -8 bytes, back to the beginning of the idleLoop. A
>backwards longJump most definitely should call
>internalQuickCheckForInterrupts.  And if the counter on
>interruptCheckCount is working, that should lead to checkInterrupts.

Alright, I'm assuming that a LONG JUMP wouldn't be needed for -8 
bytes, that's my 68K assembler biasing my opinions of what the 
bytecode code is doing, should it be a shortUnconditionalJump? also I 
didn't quite see a little if statement in the code

See the old code had

case 167:
			/* longUnconditionalJump */
	//stuff
	if (offset3 < 0) {
	/* begin internalQuickCheckForInterrupts */
	if ((foo->interruptCheckCounter -= 1) <= 0) {
	//stuff
		checkForInterrupts();
		if (plugInTimeToReturn()) {
			ReturnFromInterpret();
		}

&
case 131:
	/* singleExtendedSendBytecode */
	/* begin normalSend */
	/* begin internalActivateNewMethod */
	//stuff you'll need to look.
	// but the prim call happens before this code so it never
	// executes this, and some lots of logic exists here to
         // prevent these below statements from ever executing.

		checkForInterrupts();
		if (plugInTimeToReturn()) {
			ReturnFromInterpret();
		}


So I'm wondering perhaps the check for foo->interruptCheckCounter < 0 
in case 167 never becomes true under this condition here. Well I 
already know that because os-x has a nice gui tool to show the 
current stack back trace and once I got the plugin into the failure 
condition I could just watch it spin on the idleLoop Process.

>
>
>Remember what Yoda tells us
>"backward jumps lead to interrupt checks.
>interrupt checks lead to interrupt handling...
>and interrupt handling leads to - event routines!"
>
>tim
>
>--
>Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>Strange OpCodes: CLOUT: Call Long-distance On Unused Telephone


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