Hi Rob -
Rob Gayvert wrote:
Andreas Raab wrote:
Do you have any thoughts on how this could be handled better?
How about we just suspend the currently active process when we re-enter the interpreter? As long as the callback is synchronous (it better be) this should work just fine, right?
Yes, that should do the trick. I tried doing something like this awhile back, but couldn't get it to work reliably. I suspect the problem was that the process oop might move during a callback, in which case trying to resume it would cause a crash. It sounds like your other changes to keep oops across primitives would solve this.
Yes, although (if you look at the changes) I decided to keep this internal in the VM because it is also necessary to ensure proper resumption upon callback return (otherwise the return value will be inaccurate). So the ultimate solution goes like this:
Upon entering the callback, suspend the active process forcefully. Upon returning from the callback resume the active process forcefully(!) so that the "returning primitive" (e.g., the primitive which invoked the callback) can set the proper return value.
As far as I am aware that solves the trick completely (check out the code) at the cost of requiring that callbacks are only entered during the execution of primitives (meaning that the interpreter's state is externalized).
Cheers, - Andreas