Stream: git-wasmtime

Topic: wasmtime / PR #11684 async: add stream/future producers a...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 18:24):

rvolosatovs edited PR #11684.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 18:40):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 18:40):

alexcrichton created PR review comment:

I realize that this is optional, but it's something I've been hesitant about adding in the past (a tokio dep, even optional, in Wasmtime). If possible I'd prefer to avoid this myself (and commented below about the impl)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 18:40):

alexcrichton created PR review comment:

These feel a bit surprising to me where a drop on the host is a trap in the guest, instead I might say we should remove these and instead rely on impl<T, D, Fut> FutureProducer<D> for Fut below. In my mind it's more appropriate to map a channel closure to None in components as opposed to a trap?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 20:48):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 20:48):

rvolosatovs created PR review comment:

From what I understand futures must produce a value and the FutureProducer can only ever return None when the poll is cancelled (i.e. finish is true)

@dicej is my understanding correct?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 20:53):

rvolosatovs created PR review comment:

Other than causing a trap on host drop we could just never resolve the future, i.e. return Pending without ever waking the runtime or produce T::default()
Perhaps these implementations are fairly WASI-specific and should just stay in wasmtime-wasi, at least for now

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 20:53):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 23:53):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2025 at 23:53):

alexcrichton created PR review comment:

That's right yeah, so this would map to type Item = Option<T>, not type Item = T like it does now. Basically the mismatch in Rust channel semantics and component-model channel semantics I think should show up at the type-level, not the runtime 'this trapped' level

view this post on Zulip Wasmtime GitHub notifications bot (Sep 12 2025 at 09:49):

rvolosatovs updated PR #11684.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 12 2025 at 09:59):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 12 2025 at 09:59):

rvolosatovs created PR review comment:

I've reworked this by requiring the blanket impl futures to handle trapping directly. Although it seemed a bit dangerous to me when I originally did that, since embedders could cause a trap "on accident", I think that's fine, since these futures will actually be type bound in practice, e.g. embedders will not be able to accidentally cause a trap passing an async { Err(String::from("interface-level error")) } to FutureReader::new corresponding to future<result<_, string>>, since the Rust type system would require:

Future<Output = anyhow::Result<Result<(), String>>>

With this we don't need specialized producer wrappers, but rather can use Futures directly

view this post on Zulip Wasmtime GitHub notifications bot (Sep 15 2025 at 14:25):

alexcrichton submitted PR review:

Sounds good to me, thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Sep 15 2025 at 14:48):

alexcrichton merged PR #11684.

Last updated: Dec 06 2025 at 06:05 UTC