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@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Settled some during shipping and handling.