Callbacks, simplified.

Andreas Raab andreas.raab at
Tue Jun 6 02:06:44 UTC 2006

Hi Tim -

setjmp/longjmp are probably slow as hell but the real issue is whether 
we want to keep changes minimalistic and local (I do) or whether we're 
up for some serious rework of other parts (I'm not).

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.

Knowing you guys (and knowing myself too) those tradeoffs would be 
completely unacceptable for the VM in general - if you want to use 
callbacks and you're willing to pay a price for that then you really 
should pay the price when you use the callback and not elsewhere. That's 
why I'm opting for a setjmp/longjmp solution.

Besides, given the simplistic interface if another implementation 
becomes available it should be possible to implement an interface as 
trivial as the one proposed here. Since the interface doesn't expose 
anything about its implementation (e.g., all you get is an opaque 
callback ID) it's quite literally up to the VM how it wants to implement 
the semantics properly. It could even do this via threading and IPC if 
that were of interest.

   - Andreas

tim Rowledge wrote:
> Last time I used setjmp/longjmp was probably 1990. Back then it was 
> considered a seriously tacky thing to do and a cause of lost 
> performance.  I think BrouHaHa got non-trivially faster after I beat 
> Eliot up to get him to stop using it in the interpreter code.
> Is it less of an issue these days?
> tim
> -- 
> tim Rowledge; tim at;
> Strange OpCodes: TOAC: Turn Off Air Conditioner

More information about the Vm-dev mailing list