This uses a "reactor" mode I added to quickjs recently which exposes quickjs as a wasi library instead of a traditional main() loop. This allows the host environment to call loop_once() to step once through the JS event loop, and poll_io() to check for I/O. This way, if there's nothing available to do (VM is idle), the Go host environment (or js) can sleep until some I/O arrives. This is a lot more efficient than having Js poll for I/O.
Really interesting, I’m currently using https://github.com/fastschema/qjs but would love a bit lower-level control like your reactor and Go library provide.
loop_once may have been called run_microtask if I understand the “loop” boundary correctly?
Is there a way to be more granular in execution? Like running a single “basic block” (until a jump) or until next function call?
aperturecjs•3w ago
This uses a "reactor" mode I added to quickjs recently which exposes quickjs as a wasi library instead of a traditional main() loop. This allows the host environment to call loop_once() to step once through the JS event loop, and poll_io() to check for I/O. This way, if there's nothing available to do (VM is idle), the Go host environment (or js) can sleep until some I/O arrives. This is a lot more efficient than having Js poll for I/O.
Check it out: https://github.com/aperturerobotics/go-quickjs-wasi-reactor
nnx•3w ago
loop_once may have been called run_microtask if I understand the “loop” boundary correctly?
Is there a way to be more granular in execution? Like running a single “basic block” (until a jump) or until next function call?