Callbacks, simplified.

tim Rowledge tim at
Tue Jun 6 20:10:12 UTC 2006

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?  

tim Rowledge; tim at;
Useful random insult:- Settled some during shipping and handling.

More information about the Vm-dev mailing list