Joel (Sep 10 2025 at 04:15): Joel (Sep 10 2025 at 04:15):I have a WIT component that is imported from the host to the guest. I want to read a "record" from the host, but the execution in the host is asynchronous in the same way as the guest reading from stdin.
I see that there is a wasi:poll pollable component. Is it necessary that I have my component return a pollable to let the guest know when it is ready to read? Or do I just implement a read function and wasmtime plus my tinygo compiler magically makes that call async? Does my guest understand that that call is asynchronous, allowing other coroutines to continue execution?
Christof Petig (Sep 10 2025 at 06:12):Pollable is the old way to wake guests, but compared to 0.3 future/stream/async it doesn't compose. This means that you can't implement it in more than one guest component without running into serious overhead. There are existing implementations of async executors with pollable, but the new technology will be more reliable, soon.
Christof Petig (Sep 10 2025 at 06:13):In short pollable indicates that it will be replaced soon.
Joel (Sep 10 2025 at 06:15):So for version 0.2, I should just ignore it as it will be replaced soon? (btw thank you very much for the reply). Also, do guests multiplex i/o handles like stdio using pollable? I want to the guest to multiplex between multiple streams of records coming from the host.
Alex Crichton (Sep 10 2025 at 14:48):For WASIp2, yes, you'll want a pollable. You'll want to look around the wasi:http APIs for future-lookalike APIs and make one of those. Effectively while in WASIp3 we have future<foo> in WASIp2 you'll have to make future-foo yourself and mimick all the various functions, using a pollable internally to represent readiness.
Joel (Sep 11 2025 at 11:11):Thanks. I took a look at libc_wasm2 in tinygo to see how the tcp sockets work. I see pollable and blocking calls are used from inside tinygo.
Last updated: Dec 06 2025 at 05:03 UTC