Stream: wasi

Topic: making waitable sets from rust

Andy Wingo (Aug 26 2025 at 09:22):

Hello all :)

I would like to write a simple test to make a couple of async calls to monotonic-clock#wait_for, and wait for the first one that returns. On the low level I want to make a waitable-set and then waitable-set.join the two futures together; I assume an async function returns a future but perhaps that is a misconception. Anyway I am having trouble finding how waitable-set.join is mapped into rust and wit-bindgen. What's up?

Andy Wingo (Aug 26 2025 at 09:23):

/me summons @Till Schneidereit

Andy Wingo (Aug 26 2025 at 09:34):

it would seem that I can add a dep on wit-bindgen-rt, which has a WaitableSet binding, but it appears to be private; dunno what is going on

Till Schneidereit (Aug 26 2025 at 09:44):

I'm no expert on this by any means, but I think this test shows how to use futures::join to do this?

Till Schneidereit (Aug 26 2025 at 09:45):

with the runner.rs files in the other async tests having examples, too

Andy Wingo (Aug 26 2025 at 10:02):

waitable-set.join is more like adding an fd to an epoll set

Andy Wingo (Aug 26 2025 at 10:02):

it's not the actual operation to wait on the epollfd

Andy Wingo (Aug 26 2025 at 10:03):

but this points me in what is probably the right direction, i will see if i can futures::select_biased over a couple of async results

Till Schneidereit (Aug 26 2025 at 10:05):

join isn't the actual wait operation either, but as I said: I'm by no means an expert on this. @Roman Volosatovs might be around and know, otherwise @Alex Crichton and @Joel Dice would certainly know, but won't be awake for another few hours

Andy Wingo (Aug 26 2025 at 10:06):

/me lunch, biab

Roman Volosatovs (Aug 26 2025 at 10:36):

If you are in "Rust-land", then you can treat wait_for just as a regular async fn wait_for in Rust, and treat the result value as a regular https://doc.rust-lang.org/std/future/trait.Future.html

Perhaps this wasi:clocks test could serve as a good example https://github.com/bytecodealliance/wasmtime/blob/e767c56b824e5ce8947997b052859e050419d35b/crates/test-programs/src/bin/p3_clocks_sleep.rs

Roman Volosatovs (Aug 26 2025 at 10:37):

so futures::select_biased should work just fine (and if it does not - that's a bug we should fix)

Andy Wingo (Aug 26 2025 at 12:23):

neat, our tests are similar https://github.com/WebAssembly/wasi-testsuite/pull/120/files#diff-0308e5f25267659be76c7a48f5e83bed5a6258d013f20502300ef18c72411407

Andy Wingo (Aug 26 2025 at 12:24):

what i am interested in testing tho is when there are multiple futures outstanding

Joel Dice (Aug 26 2025 at 13:10):

Keep in mind you can always bypass wit-bindgen-rt's abstractions and import and call the intrinsics directly. We do that here and here, for example.

Andy Wingo (Aug 26 2025 at 13:11):

oh that's very funny, thank you for that

Alex Crichton (Aug 26 2025 at 14:29):

Part of this is where it's kind of hard to figure out what exactly you're testing. For example right now you're moreso testing tooling like wasm-component-ld than you're testing the raw component model (e.g. writing source code that's compiled vs writing *.wast). When writing Rust you're more testing the bindings in the wit-bindgen crate than the async intrinsics themselves.

Given that I feel like the best answer here is "what are you trying to test" which lends itself to an answer of how to test it. For example:

• When testing "shapes" of a component or raw intrinsics, it can be useful to use *.wast or *.wat
• When testing a raw intrinsic, but in the context of something else more complicated, it might be mostly useful to use C which has a much more raw feeling than Rust. This will rely more on wit-bindgen and wasm-component-ld, however.
• When testing high-level interactions I'd recommend Rust because it's far easier to read/write tests using async

Alex Crichton (Aug 26 2025 at 14:29):

I realize though that not all of this is up-and-running as of this red hot second, but it's things where I would personally say it's best to avoid raw definitions of APIs where you can because that's technically an "unstable layer" which is yet more we'd have to change if we ever tweak it (vs just changing the bindings generator)

Alex Crichton (Aug 26 2025 at 14:30):

It's sufficient, but a case where C may be better suited for example

Last updated: Dec 06 2025 at 06:05 UTC