Async canonical ABI option not respected on all intrinsics

[alexcrichton]

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

• future/stream reads currently require async
• future/stream writes currently require async
• cancelling future/stream writes ignores async
• cancelling future/stream reads ignores async

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.

[lukewagner]

Yep, will do

[lukewagner]

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.

[lukewagner]

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.

[dicej]

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?

[alexcrichton]

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)

[dicej]

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.