Stream: general

Topic: Giving control flow back at host functions

Julien Cretin (ia0) (Mar 29 2023 at 16:51):

Hi all, AFAICT all existing runtimes take control of the execution flow when an exported function is called and don't give it back until the function returns. I'm wondering why this choice. In my interpreter I'm taking the other approach of giving back control flow whenever a host function is called, similar to say how async works in Rust (I'm also planning to do that based on "fuel" / time quota). This gives more control to the embedder, which may implement scheduling between multiple wasm execution without support from the OS or hardware (i.e. within the same execution flow). So I'm wondering if this is a deliberate choice to take control of execution on exported function calls? (thus removing control from the embedder)

Julien Cretin (ia0) (Mar 29 2023 at 16:52):

Here are some links:

• The interpreter: https://docs.rs/wasefire-interpreter/latest/wasefire_interpreter
• The rational for writing it: https://google.github.io/wasefire/faq.html#why-implement-a-new-interpreter

Alex Crichton (Mar 29 2023 at 16:57):

The main difficulty with handing back control is somehow handling the wasm stack (which for Wasmtime is the same as the native stack). Handling that in a naive way to hand back control arbitrarily runs the risk of tanking performance, and otherwise solutions which don't compromise on performance are often very tricky to get right or significantly more involved.

That being said Wasmtime does have support for async so it's possible to suspend a wasm computation whenever a host function is called. It's not necessarily modeled precisely as that but you can achieve it that way. Additionally with epochs and fuel (both of which Wasmtime supports) you can get guests to periodically yield back to the host as opposed to always taking control

Alex Crichton (Mar 29 2023 at 16:58):

note, though, that for us the only implemented way to yield back control to the host is if wasm was executed on a separate stack so suspending the stack is just saving it off in memory. This means, though, that the wasm must have started on a separate stack to begin with as opposed to being able to retroactively move it to a side stack or something like that

Julien Cretin (ia0) (Mar 30 2023 at 09:03):

Thanks for the clear response! So this is for performance when the stack is shared. I think I can see how to use async to achieve the same effect. Regarding starting wasm on a separate stack, I guess this is automatic with async support, I couldn't find an explicit configuration.

Last updated: Dec 23 2024 at 13:07 UTC