search

wasmi-labs / wasmi

WebAssembly (Wasm) interpreter.
https://wasmi-labs.github.io/wasmi/
Apache License 2.0
1.52k stars 274 forks source link

Thoughts on js-promise-integration #1050

Closed tommie closed 1 month ago

tommie commented 1 month ago

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 commented 1 month ago

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.)

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.

tommie commented 1 month ago

Thank you, that sounds great.

I could make a PR for the README to include the proposal and suggest resumables, if you'd like.

Robbepop commented 1 month ago

Thank you, that sounds great.

I could make a PR for the README to include the proposal and suggest resumables, if you'd like.

A write-up is probably welcome, though I would prefer to have a discussion item for it in our Wasmi discussions GitHub forums. So we can simply refer people to the write-up. :)

Can we close this issue now? :)

tommie commented 1 month ago

Aight. Thanks.