Joel (Sep 08 2025 at 00:24): Joel (Sep 08 2025 at 00:24):I implemented a WIT bindgen host-side set of functions that utilize the WIT "future" keyword. In Rust on the host side, I need to return a FutureReader. But, I only have a WasiCtx and ResourceTable. It does not seem possible to use a FutureReader because I need access to the store and instance objects. Is there a way to generate a FutureReader with just a WasiCtx? I just want to asynchronously return a u64 after a database lookup.
Alex Crichton (Sep 08 2025 at 04:06):I think you'll want this commit, where in the meantime you can use the async option and get to the store via an Accessor
Joel (Sep 08 2025 at 10:35):Thanks for the pointer! I see that in the host implementation all the calls are already async. Why is it necessary to set "future" in the WIT file and use FutureReader instead of just using async functions on the Host side?
Alex Crichton (Sep 08 2025 at 14:25):I might be missing something perhaps? Are you writing these WIT files yourself or are you using, for example, WIT files for WASI?
The FutureReader type corresponds to future<T> in WIT, no more and no less. Whether or not a function is async on the host defaults to the async annotation in WIT but can also be configured on the host too
Joel (Sep 08 2025 at 14:27):Yes, I am writing my own WIT files. I have a simple function call that returns a u64. But I am not sure whether to have "future<result<u64,error-code>>", or just "result<u64,error-code>" as the response. i just want to avoid the WIT for WASI runtime to no hit a deadlock due to guest code interacting with the host.
Alex Crichton (Sep 08 2025 at 14:33):The signatures are pretty similar, but for example you can transfer a future to other components where you can't transfer a subtask (e.g. an async function). Which is more appropriate sort of depends on the context of your embedding and APIs
Last updated: Dec 06 2025 at 05:03 UTC