[BUG][FIX] netscape browser plugin change

Tim Rowledge tim at sumeru.stanford.edu
Sat Aug 10 15:07:16 UTC 2002


John M McIntosh <johnmci at smalltalkconsulting.com> is claimed by the authorities to have written:


> 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?
No, the long unconditional is the only one to do a backwards jump for
loops.
> 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) {
	^^^^^^ this is checking for backwards branch, do the interrupt stuff if so
> 	/* begin internalQuickCheckForInterrupts */
> 	if ((foo->interruptCheckCounter -= 1) <= 0) {
> 	//stuff
> 		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.
I don't suppose there is some problem with the compiler handling the
foo->interruptCheckCounter -=1 instead of the all-other-platform code
interruptCheckCounter -=1 ? Take a look at the assembly.

And just generally, I mean, yuck. Has anyone bothered to look at
checkInterrupts recently? Blech. What a mess.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>From C:\*.* to shining C:\*.*




More information about the Squeak-dev mailing list