Karel Hrkal (kajacx) (Apr 13 2024 at 07:01): Karel Hrkal (kajacx) (Apr 13 2024 at 07:01):Hello, is it possible to run wasmtime and wasmtime-wasi version 19.0 synchronously? I have all imported methods synchronous, and having the exported methods be asynchronous makes it basically impossible to call them in my situation and I really don't want to crate a tokio runtime for every exported method call.
If the user doesn't need to use async imported methods, then there should not be any async or await anywhere in the code.
Karel Hrkal (kajacx) (Apr 13 2024 at 07:31):Ok, I managed to get it to work, but there are problems. First, when redirection IO, I have to use the async Subscribe trait, which means the asyncness is not truly gone. Also, when looking at the code (here for example), It looks like it just calls the async methods anyway and then blocks on a runtime.
I assume this must have some toll for performance, and for completely no reason, since all the imported methods are synchronous anyway (so what are are actually awaiting?). I would be happy to work on a PR to properly fix this and not have any async or await in synchronous wasi, providing proper sync variants for WasiCtxBuilder for example.
Dave Bakker (badeend) (Apr 13 2024 at 07:44):https://github.com/bytecodealliance/wasmtime/issues/7973#issuecomment-1960513214
Dave Bakker (badeend) (Apr 13 2024 at 07:46):That comment sums up why it currently is the way it is.
Karel Hrkal (kajacx) (Apr 13 2024 at 10:09):@Dave Bakker (badeend) I have no problem with async wasi using tokio, but there should be an option to turn async off and have it actually be off. As the comment says, The only way to change that behavior would be to rewrite wasmtime-wasi with a completely different internal architecture, to solely use synchronous Rust. That's exactly what I want. Obviously you cannot use real http connections, but everything else should be doable in sync Rust. I am willing to do the rewrite, the only question is if that PR would be accepted. If not, I can always release it as a separate crate called wasmtime-wasi-sync or something, if you don't have a problem with wasmtime being in the name even though it is not from the wasmtime team.
Dave Bakker (badeend) (Apr 13 2024 at 10:23):I'm not the right person to answer that. Maybe someone else can comment on this.
But do know that you're in for a lot of work. :smile: Also, how are you planning to implement pollables (and notably poll::poll) in an all-sync implementation ?
Karel Hrkal (kajacx) (Apr 13 2024 at 10:31):Also, how are you planning to implement pollables (and notably poll::poll) in an all-sync implementation ? Just make the trait sync. It's up to the user to provide a sync implementation. As a user, I don't need real file IO (writing to a in-memory file is fine) or network connectivity, so I don't see any problems.
Ryan Levick (rylev) (Apr 14 2024 at 15:39):@Karel Hrkal (kajacx) If you're targeting the command world, you can use this to instantiate sync versions of the world. In general, wasmtime-wasi considers async the default, but provides a sync module which is the equivalent but synchronous.
Pat Hickey (Apr 14 2024 at 22:24):"just make the trait sync" doesn't answer any of the hard questions for how poll would work in synchronous rust, nor how any of the knock-on effects would be handled, per my long comment linked above
Pat Hickey (Apr 14 2024 at 22:26):the sync wrapper hides the use of tokio and async as an implementation detail, but theyre still there. eliminating the dependency on tokio and/or async rust altogether would be a total redesign of all the hard parts of wasmtime-wasi.
Pat Hickey (Apr 14 2024 at 22:28):since all the imported methods are synchronous anyway (so what are are actually awaiting?)
the thing being awaited is the readiness of pollables (and therefore streams and everything else)
Pat Hickey (Apr 14 2024 at 22:31):readiness of pollable is the crux of all of wasi 0.2. that concept is only going to get embedded deeper into the runtime as we evolve towards CM 0.3, because calls between components will (in some circumstances) gain that concept of waiting for readiness
Karel Hrkal (kajacx) (Apr 15 2024 at 05:17):I'll be honest, I don't understand what poll and subscribe are for. I have looked at custom IO redirection, successfully redirection output to an in-memory object, and I completely ignored the Subscribe trait (provided an empty implementation).
What I want the most is std out/err capturing, also clocks or random would be great. I don't really need file IO (at least yet), and even when I will need it, I don't see why file IO couldn't be implemented in sync Rust.
After trying to rework the wasmtime-wasi crate to be fully sync, I can see that it is no trivial task as the asyncness is embedded deep in the structure of the code. But it is possible, or, at the very least, it is possible to make a new, fully sync implementation. I decided to not work on that right now, since it would affect only the desktop runtime, mut bayberry some day in the future.
Ramon Klass (Apr 15 2024 at 08:28):see the last paragraph Pat posted. Wasi-0.3 will require an async executor of some form, it is unavoidable.
YouTube - A stream of consciousness on the future of async in the Component Model by Luke Wagner @ Wasm I/O 24 this talk gives a nice overview of why and how
poll and readiness are the core concepts behind async programming, the rust docs about Futures, Poll and Wakers should help with understanding what those do
Karel Hrkal (kajacx) (Apr 23 2024 at 08:57):Ok, thanks for the messages. At least I know that proper wasi sync implementation is not going to happen. If it will become a problem for me (performace-wise), I can always try to implement it myself.
Last updated: Dec 23 2024 at 12:05 UTC