Stream: git-wasmtime

Topic: wasmtime / issue #11611 Async canonical ABI option not re...

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

alexcrichton opened issue #11611:

This is an implementation TODO that still needs to be resolved for full component-model async support:

Subtask cancellation, however, does handle it.

@lukewagner would you be up for writing some *.wast spec tests for these behaviors in parallel? I'm also not sure if there's tests for async in lift/lower options yet as well (e.g. mixing/matching async lifts/lowers) which would also be good to test.

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

alexcrichton added the wasm-proposal:component-model-async label to Issue #11611.

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

alexcrichton assigned dicej to issue #11611.

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

lukewagner commented on issue #11611:

Yep, will do

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 16:27):

lukewagner commented on issue #11611:

Oh, also, to this part:

I'm also not sure if there's tests for async in lift/lower options yet as well (e.g. mixing/matching async lifts/lowers) which would also be good to test.

async-calls-sync.wast has an (async, sync, async) hamburger that tests a number of the interesting/hard cases and a number of the other tests have sync calling async in other combinations.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 16:51):

lukewagner commented on issue #11611:

Based on this test, it looks like validation does currently reject async on {stream,future}.cancel-{read,write} and subtask.cancel and async is also rejected on resource.drop as a parsing error.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 16:56):

dicej commented on issue #11611:

Based on this test, it looks like validation does currently reject async on {stream,future}.cancel-{read,write} and subtask.cancel and async is also rejected on resource.drop as a parsing error.

Yeah, that does ring a bell now; I think we punted on a few variations. So it sounds like we only need to support synchronous {stream,future}.cancel-{read,write}. Do we need to support synchronous {stream,future}.{read,write}, or did we punt on that for now, also?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:01):

alexcrichton commented on issue #11611:

For the intrinsics in Wasmtime you'll need -Wcomponent-model-async-builtins since it's separately gated from -Wcomponent-model-async, and that should get the intrinsics passing validation. One of the main blind spots we have right now in the implementation is that for non-async intrinsics they read/write cancellation ones aren't correctly handling the case that blocking should happen. So one major thing that I think is worthwhile to test is cancelling a read/write in a way that needs to block the calling task and ensuring that BLOCKED doesn't get returned.

For resource.drop async bits Wasmtime doesn't currently have any support for that IIRC, so that can be split out to a separate file for now that we'll need to implement later.

Yeah, that does ring a bell now; I think we punted on a few variations

To be clear, we punted on the async versions, not the versions that should handle BLOCKED. The BLOCKED code should never be returned AFAIK (which it currently does).

Also, IMO we should either rip out everything from Wasmtime that doesn't match the spec or we should match the spec. I don't want to be in a situation where we half-implement a historical snapshot of the spec. Basically if we try to support async then we should, even if it's a separate feature gate, or we should remove the support that we have. (I know this is a point you and I differ on @dicej historically so we can talk more about this too)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:02):

dicej commented on issue #11611:

To be clear, we punted on the async versions, not the versions that should handle BLOCKED. The BLOCKED code should never be returned AFAIK (which it currently does).

Right, that's what I mean, and I'm working on fixing that now.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:03):

alexcrichton commented on issue #11611:

Ok yeah my reading comprehension is lacking today as it does many days...

Do we need to support synchronous {stream,future}.{read,write}, or did we punt on that for now, also?

Yes, we need to support this. We didn't punt on this.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:08):

alexcrichton commented on issue #11611:

For posterity https://github.com/bytecodealliance/wasmtime/pull/11623 is an example test that is failing due to this issue

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:45):

dicej commented on issue #11611:

Making progress: https://github.com/bytecodealliance/wasmtime/pull/11625

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 17:52):

dicej commented on issue #11611:

It just remembered (after Alex pointed it out to me yesterday) that a pure WAST test for {stream,future}.cancel-{read,write} won't exercise my fix here anyway, since it only applies when the other end is owned by the host. I'll work on adding some tests to component-async-tests.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 06 2025 at 19:34):

lukewagner commented on issue #11611:

Alright, here's a test for sync stream.{read,write} that blocks, switches, switches back and then completes (but currently fails with "synchronous stream and future writes not yet supported").

view this post on Zulip Wasmtime GitHub notifications bot (Sep 08 2025 at 19:52):

dicej commented on issue #11611:

#11625 Addresses the cancel-{read,write} part of this issue. I'll work on the {read,write} part next.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 08 2025 at 22:22):

lukewagner commented on issue #11611:

Just as a interesting side note, thinking about what it would take to be able to write a pure .wast test that exercised the BLOCKED case of sync cancel-{read,write}, it'd just be this stream.read-{data,complete} feature we already discussed adding at some point in the future in the stdio issue.

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

dicej commented on issue #11611:

https://github.com/bytecodealliance/wasmtime/pull/11645 adds support for synchronous {stream,future}.{read,write} calls, but I'm hitting a new issue when running Luke's sync-streams.wast test, so I'm going to debug that before I close this issue.

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

dicej commented on issue #11611:

https://github.com/bytecodealliance/wasmtime/pull/11655 should finish this up, finally (and extends my streak of only posting PRs ending in 5 for this issue).

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

dicej edited a comment on issue #11611:

https://github.com/bytecodealliance/wasmtime/pull/11655 should finish this up, finally (and extends my streak of only posting PRs ending in 5 for this issue: #11625, #11645, and #11655).

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

alexcrichton closed issue #11611:

This is an implementation TODO that still needs to be resolved for full component-model async support:

Subtask cancellation, however, does handle it.

@lukewagner would you be up for writing some *.wast spec tests for these behaviors in parallel? I'm also not sure if there's tests for async in lift/lower options yet as well (e.g. mixing/matching async lifts/lowers) which would also be good to test.

Last updated: Dec 06 2025 at 06:05 UTC