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