tim at rowledge.org
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
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 rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Settled some during shipping and handling.
More information about the Vm-dev