Brennon Loveless (Jan 27 2024 at 05:53): Brennon Loveless (Jan 27 2024 at 05:53):Hey everyone, I'm hoping that this is just something dumb that I don't understand. I'll preface this by saying that I'm new to WASM/WASI/and rust. I'm trying to write a host in rust that can run wasm modules essentially as plugins. Even more simple than that I've put together just a simple reproduction of the error I'm seeing here. In theory you should be able to see the same error by running make in that repo.
It seems that using go 1.21 wasip1 to build isn't working quite right. What is interesting is that it seems to execute the program correctly (I see the Hello World output) but it seems to have a hard time exiting the module properly. And prints out a strange message "Exited with i32 exit status 0" which seems like it would imply that it exited successfully.
A separate question is that it takes 4 seconds to load the module from a file in my program but the wasmtime cli is able to run it instantly. I'm wondering if I'm doing something else wrong here.
Thanks!
Till Schneidereit (Jan 27 2024 at 13:16):Hi Brennon :wave: This is a bit subtle, and something we'd ideally handle automatically—but which isn't easy to handle internally for you.
The issue is that wasm modules don't have a way to make the entire host process exit as a call to exit in a native application would. Instead, the WASI implementation of the exit function raises an error in the host application, which can be handled in different ways. What you're seeing is the default of not handling the error. Here's an example of how you can instead test it and silently exit the host application—or do whatever else is right in your circumstances: https://github.com/bytecodealliance/wasmtime/blob/27d3ef2ff5652f7dd6c5af07e6d9ee1587762030/crates/bench-api/src/lib.rs#L545-L551
Brennon Loveless (Jan 27 2024 at 14:10):This makes a lot of sense! Thank you for the explanation and example!
Peter Huene (Jan 27 2024 at 19:17):A separate question is that it takes 4 seconds to load the module from a file in my program but the wasmtime cli is able to run it instantly. I'm wondering if I'm doing something else wrong here.
This is likely caused by running your host from a debug build, so try running with cargo run --release.
Additionally, you will want to enable the compilation cache via Config.cache_config_load_default as that will ensure that your host loads a previously-compiled version of your module if your module does not change between runs.
Brennon Loveless (Jan 27 2024 at 20:35):Awesome! I didn’t even thing about debug vs release mode. I was digging around the wasmtime cli code and didn’t see any magic bullets but of course o didn’t think about trying release mode :)
thank you!
Last updated: Dec 23 2024 at 13:07 UTC