You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is this something that would be easy to modify WASMI to support? I'm guessing it would use the common Rust async API, simmilar to how it's described for JavaScript.
Context This would solve a headache I have (currently using wasm3): I want an event main loop, but once I start WASM, it has to do everything blocking, unless I make the WASM code async. Since WASM is already interpreted and should be trivially re-entrant, it seems the interpreter could do more to help me "get out" again while waiting for I/O. (Running on the second core of RP2040.)
When using Wasmi's resumable functions, errors returned from called host functions will yield back the execution and also make it possible for the host side to resolve the error and resume the call afterwards. So whenever your host functions would perform I/O tasks you could instead return a host error that stores all the needed information about the I/O operation. Then Wasmi would yield control back to the host side where the async I/O operation could be performed just to resume the Wasm execution via Wasmi, finally.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There is a proposal to allow imported functions returning a Promise, and thereby suspending WASM execution, essentially turning the entire WASM call into a Promise: https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md
V8 talks about it here: https://v8.dev/blog/jspi
Is this something that would be easy to modify WASMI to support? I'm guessing it would use the common Rust async API, simmilar to how it's described for JavaScript.
Context This would solve a headache I have (currently using wasm3): I want an event main loop, but once I start WASM, it has to do everything blocking, unless I make the WASM code async. Since WASM is already interpreted and should be trivially re-entrant, it seems the interpreter could do more to help me "get out" again while waiting for I/O. (Running on the second core of RP2040.)
@Robbepop responded in #1050, saying:
It should be possible to solve this headache with Wasmi's resumable function calls:
https://docs.rs/wasmi/0.32.1/wasmi/struct.Func.html#method.call_resumable
When using Wasmi's resumable functions, errors returned from called host functions will yield back the execution and also make it possible for the host side to resolve the error and resume the call afterwards. So whenever your host functions would perform I/O tasks you could instead return a host error that stores all the needed information about the I/O operation. Then Wasmi would yield control back to the host side where the async I/O operation could be performed just to resume the Wasm execution via Wasmi, finally.
This is how smoldot solves a very similar use case. (https://github.com/smol-dot/smoldot/blob/main/lib/src/executor/vm/interpreter.rs)
Some people believe that resumable calls are a more powerful concept than async calls.
It sounds like wasmi already covers the js-promise-integration proposal with existing mechanisms.
Beta Was this translation helpful? Give feedback.
All reactions