Stream: wasi

Topic: Rust async ecosystem and wasip3

Nicola Krumschmidt (Oct 21 2025 at 16:07):

With WASI 0.3 on the horizon, I'm curious about its future support within the Rust async ecosystem, particularly with regard to its compatibility with tokio. I have a potential use case involving streaming results asynchronously from the guest to the host. Once tokio supports the wasip3 target, will I be able to use any crate that provides asynchronous functionality and relies on tokio (e.g., tokio-postgres) in the guest? Or will each crate have to add support for wasip3 individually?

Ludea (Oct 21 2025 at 16:13):

There is https://github.com/tokio-rs/tokio/pull/6893

Ludea (Oct 21 2025 at 16:22):

You can use https://github.com/bytecodealliance/wstd instead

Lann Martin (Oct 21 2025 at 16:22):

Once tokio supports the wasip3 target, will I be able to use any crate that provides asynchronous functionality and relies on tokio (e.g., tokio-postgres) in the guest?

There won't be a universal answer here. Some crates will work immediately, some will work eventually, and some (hopefully very few!) will likely never work.

Lann Martin (Oct 21 2025 at 16:27):

Or will each crate have to add support for wasip3 individually?

This shouldn't be necessary, though a few common dependencies like hyper may need individual work toward support to enable dependent crates.

Nicola Krumschmidt (Oct 21 2025 at 17:26):

Thanks! All of that makes sense so far. There is one thing I'm wondering about, though. If I understand correctly, to call an async function that transitively calls a function from tokio, the call must happen in a tokio runtime context. However, if the function is called from an exported guest function, the runtime runs inside the host, so there is no runtime that the guest is aware of.

Pat Hickey (Oct 21 2025 at 17:28):

you'll never see that sort of connection between guest and host.

Pat Hickey (Oct 21 2025 at 17:29):

running tokio inside the guest means that the guest tokio will use wasip3 as its syscall layer. it won't (can't, and shouldn't) know anything about the host environment it is running inside, just that the environment provides wasip3

Pat Hickey (Oct 21 2025 at 17:31):

so, the guest tokio (linked to by any libraries using tokio inside the guest) will have to satisfy all of its needs from the external world (connecting, accepting, sending and recieving data on sockets, opening files, timers, etc) via wasip3. if the host happens to use a tokio for implementing wasip3, thats an implementation detail out on the host where the host tokio will be making linux (or mac or etc) syscalls to implement its functionality. but the two will always be in totally separate memory spaces, symbols from one tokio wont ever resolve to the other

Nicola Krumschmidt (Oct 21 2025 at 18:01):

But if you just call a tokio function from an exported guest function, there would be no tokio runtime running inside the guest, would there? If I called a tokio function outside of the tokio runtime context today, it will panic, but when the same function is called from a guest that is compiled to wasip3, it should still work.

Alex Crichton (Oct 21 2025 at 18:04):

That's right yeah, the guest would be responsible for setting up and managing the tokio runtime within itself and calls to its exports. This might be via a wasi-specific API in tokio or something like that

Nicola Krumschmidt (Oct 21 2025 at 20:56):

Ah, I see. Thanks! So, calling an async function alone won't suffice. Has anyone experimented with what that might look like in terms of implementation in tokio? I'm very interested to see how it will work.

Pat Hickey (Oct 21 2025 at 21:34):

there have been experiments porting tokio to wasip2, but none yet to wasip3

Pat Hickey (Oct 21 2025 at 21:36):

wstd is a much smaller runtime than tokio that works for wasip2 today https://github.com/bytecodealliance/wstd. it will be ported to wasip3 in the future

Pat Hickey (Oct 21 2025 at 21:36):

its worth considering what, exactly, you need from tokio. If you are just using tokio::net, tokio::time, tokio::task::spwan, that stuff works great with wstd today (though under a different crate name)

Pat Hickey (Oct 21 2025 at 21:39):

if you are trying to use e.g. tokio-native-tls that uses the (linux, macos, windows) native tls - that wont work today, that doesnt (yet) exist for wasi. (there is a wasi-tls proposal in progress and will eventaully be possible)

Pat Hickey (Oct 21 2025 at 21:42):

if you are using features of tokio's multi-threaded executor (e.g. spawn_blocking) those wont work on wasip3 either, because those require threads, and wasip3 will not have threads at launch (they will come later, and they will initially be cooperative threads, not preemptive). (and its sort of a traditional-os-ism to need blocking syscalls, which along with long-running cpu-bound computations is why spawn_blocking exists, in wasip3 all syscalls can be made async, but thats neither here nor there)

Last updated: Dec 06 2025 at 06:05 UTC