Skip to content

Conversation

@lukewagner
Copy link
Member

This PR builds on #363 to add future and stream type constructors along with the associated canon built-ins ({stream,future}.new, {stream,future}.{read,write}, {stream,future}.cancel-{read,write}). It also generalizes the "async_subtasks" table to also hold futures and streams, renaming it to be the "waitables" table and renaming subtask.drop to waitable.drop. Lastly, a new canonopt called always-task-return is added so that sync-lifted exports can use task.return to return their value, which you need if you want to return a stream or future from a synchronous function.

I'd suggest reading the new text in Explainer.md/Binary to get a short overview of the concrete syntactic/binary additions, then Async.md to get the high-level summary, then CanonicalABI.md to get the full details.

@dicej
Copy link
Collaborator

dicej commented Oct 30, 2024

An earlier version of the design had separate drop built-in functions for the readable and writable ends of streams and futures, e.g. {stream|future}.drop-{reader|writer}, and the ABI included a t:<typeidx> for each of those, allowing tools and host implementations to know statically what specific type to expect, just like we've done for {stream|future}.{read|write|new}.

For symmetry with the rest of the built-ins, could we split waitable.drop back into subtask.drop and {stream|future}.drop-{reader|writer}? That would also make it clearer that {stream|future|.drop-writer can take an optional error parameter, but {stream|future}.drop-reader cannot.

@lukewagner
Copy link
Member Author

@dicej Great point, and agreed. Split back up in this commit.

@lukewagner
Copy link
Member Author

For visibility: this commit adds error and its associated canon built-ins, closing the TODOs in the original PR.

@lukewagner
Copy link
Member Author

Thanks for all the excellent feedback everyone! I think the comments are dying down and it sounds like this is on a convergence path with @dicej's impl, so if nothing new pops up, I think I'll merge mid next week (and then we can continue to iterate on async in new issues and PRs).

FWIW, I think the next change I'd like to make is a PR that removes the DONE state from subtasks, which should simplify things and allow bindings for async borrows to make sense, and, after that, go through the top bullets of Async.md#TODO.

@lukewagner
Copy link
Member Author

One other update: for both the pragmatic short-term benefit of avoiding parsing conflicts with the error resource type (defined by wasi:io/error) and, more generally, to help make it clear that it's just meant to convey non-deterministic, debugging-oriented contextual data, this commit renames error to error-context. This also nicely distinguishes error-context from the error case of the result variant (which contains the "whole" error value, including the WIT-defined error payload value).

dicej added a commit to dicej/wasm-tools that referenced this pull request Nov 5, 2024
This adds support for encoding and parsing components which use the [Async
ABI](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md)
and associated canonical options and functions, along with the [`stream`,
`future`, and `error`](WebAssembly/component-model#405)
types.

Note that the `error` type was recently (about 30 minutes ago) renamed to
`error-context` in Luke's spec PR.  I haven't updated this implementation to
reflect that yet, but will do so in a follow-up commit.  That should allow us to
avoid conflicts with existing WIT files that use `error` as a type and/or
interface name.

This does not include any new tests; I'll also add those in a follow-up commit.

See bytecodealliance/rfcs#38 for more context.

Signed-off-by: Joel Dice <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet