Callbacks, simplified.

John M McIntosh johnmci at
Tue Jun 6 20:28:04 UTC 2006

The older (way older) macintosh os-8.x based netscape browser plugin  
would run the interpreter loop for N instructions (milliseconds) I  
think, then exit the loop, thus halting the envrionment and return  
control to the browser, on the next call from the browser we would  
reenter the interpreter loop and process the next bytecode as if  
nothing happened...
I believe stubs for that logic still exist.

On 6-Jun-06, at 1:10 PM, tim Rowledge wrote:

> On 6-Jun-06, at 12:59 PM, Dave Mason wrote:
>>> An alternative I have pondered was to give interpret() an argument,
>>> namely a pointer to a variable that external code can set when it's
>>> time to return. This would solve the problem without doing
>>> setjmp/longjmp, BUT it would come at the cost of a
>>> pointer-dereferencing and test at every single bytecode (at the very
>>> least at each primitiveResponse but there are gotchas with that) and
>>> would potentially defeat the dispatch optimization in gnuification.
>> I don't know the vm internals at all, but a standard place to put  
>> such
>> tests in other contexts is on backward-jumps and method-returns  
>> (maybe
>> that's what primitiveResponse is).  The cost of that wouldn't be too
>> significant.
> That's where the interruptCheck stuff is done Dave; and if it is  
> plausible to hang off that (?) then all that would need doing is to  
> call forceInterruptCheck() from the plugin to get a fuller check  
> ASAP. IF (big if in glowing capitals) handling callbacks could be  
> dealt with within the typical interrupt checking work it would be a  
> bit less onerous than at arbitrary points.
> How are you proposing to deal with the callback at the higher  
> levels? Is the plugin going to be allowed to cons up a message and  
> 'send' it? Or.....?
> tim
> --
> tim Rowledge; tim at;
> Useful random insult:- Settled some during shipping and handling.

John M. McIntosh <johnmci at> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.

More information about the Vm-dev mailing list