WASI 0.3 is official, and async is now native to WebAssembly Components. The WASI Subgroup voted to ratify WASI 0.3.0, rebasing WASI onto the WebAssembly Component Model’s async primitives. The 0.3.0 specification is now stable, and runtime and toolchain support is landing now.
The work that wasi:io in WASI 0.2 used to do (pollables, input-streams, output-streams) is now part of the canonical ABI, where the Component Model now offers these primitives natively. As a concequence of that, most of the changes from WASI 0.2 to 0.3 are entirely mechanical and significantly simplify the signatures we had before. The new async
primitives are part of the Component Model’s canonical ABI,
enabling bindings generators to emit idiomatic async bindings for their given
language.
In WASI 0.2 each component needed its own event loop/async runtime. That meant that individual components could be run on a host, but there was no way for those event loops to coordinate with one another. If a component used streaming or async APIs, it couldn’t be composed with any other components.
WASI 0.3 makes it so the host is now the one in charge of managing the one event loop that is shared by all components. This is enabled by adding stream<T>, future<T>, and async as first-class constructs to the canonical ABI:
stream<T> and future<T> function like resource types: each is an owned handle, passing one across a component boundary transfers ownership from caller to callee. Unlike resource types, they can’t be borrowed.future, the runtime schedules whichever task is awaiting it, even if it was passed through multiple component boundaries. The writer that delivers that value might be the host, another component, or even the same component that holds the read end.io_uring and Windows’ IOCP/IoRing APIs. An epoll/kqueue-style readiness API can be emulated on top of this for programs which need the compatibility.async funcs directly. Gone is the three-step start-foo / finish-foo / subscribe dance from WASI 0.2.Most of the changes in the 0.3 interfaces are entirely mechanical. WASI 0.2 had to perform some acrobatics to make async work, but now that async is native to the component model we can write the same things we did before but much more ergonomically. Here is an overview of the patterns we were encoding in WASI 0.2 with the wasi:io package, and what those patterns now look like in 0.3 with Component Model async:
WASI 0.2 (wasi:io) |
WASI 0.3 (Component Model) |
|---|---|
resource pollable |
future<T> |
resource input-stream |
stream<u8> |
resource output-stream |
stream<u8> (written-to direction) |
poll(list<pollable>) |
await on a future (runtime-handled) |
subscribe() on resource |
return a future<...> from the call |
start-foo / finish-foo |
foo: async func(...) |
A problem with WASI 0.2 was that it surfaced terminal errors inline on each read call on the stream. That meant callers only learned the outcome if they kept reading. If readers stopped early they could not distinguish between a stream close and an error. In WASI 0.3 streams now return an additional future which resolves independently of how much of the stream is consumed, solving the stream status problem of WASI 0.2:
// WASI 0.2
read-via-stream: func() -> result<input-stream, error-code>;
// WASI 0.3
read-via-stream: func() -> tuple<stream<u8>, future<result<_, error-code>>>;
One of the super powers of the component model is that it makes it trivial to
create bindings to and from other languages. With the addition of first-class
async it means guest binding generators can leverage that to create async
bindings that feel native to that language. Take for example the wasi:http/handler
interface. This interface exposes one function, handle, which is marked async:
interface handler {
handle: async func(request: request) -> result<response, error-code>;
}
To implement an HTTP server in Rust with this, we can use the wit-bindgen
crate. This maps the interface handler to a trait Guest, and maps the
handle: async func to an async fn handle:
use wasi::http::types::{ErrorCode, Request, Response};
impl Guest for Component {
async fn handle(request: Request) -> Result<Response, ErrorCode> {
// ...
}
}
Async support for guest binding generators is also in-progress for many languages including Python, JavaScript, C#, and C. All of these languages rely on stackless coroutines. But the Component Model’s async ABI was designed from the ground up to accomodate both stackful and stackless coroutines side-by-side. An example of a language with those is Go. Instead of exposing async and non-async functions, Go’s runtime is able to convert synchronous-looking calls to async calls, and provides concurrent execution via virtual threads called “goroutines”.
Using componentize-go we can implement an HTTP server by exporting a func Handle. This enables streaming bodies via goroutines that do blocking calls. The runtime then parks the goroutine at the ABI boundary and resumes it when the stream is ready, without blocking the rest of the program:
package export_wasi_http_handler
import (
. "wit_component/wasi_http_types"
. "go.bytecodealliance.org/pkg/wit/types"
)
func Handle(request *Request) Result[*Response, ErrorCode] {
tx, rx := MakeStreamU8() // ← 1. Create a channel pair
go func() { // ← 2. Spawn a virtual thread
defer tx.Drop()
tx.WriteAll([]uint8("Hello, world!")) // ← 3. Write into the channel
}()
response, send := ResponseNew( // ← 4. Create an HTTP response
FieldsFromList([]Tuple2[string, []byte]{
{F0: "content-type", F1: []byte("text/plain")},
}).Ok(),
Some(rx), // ← 5. Pass the receiver as the HTTP body
trailersFuture(),
)
send.Drop()
return Ok[*Response, ErrorCode](response) // ← 6. Return the HTTP response
}
Now that WASI 0.3 has been launched with support for component model async, guest toolchains and host runtimes will be unblocked to begin stabilizing all of these. Over the coming weeks and months you can expect individual projects to begin announcing support for WASI 0.3.
wasi:httpThe interface that has seen the most change is wasi:http. We haven’t just
mechanically converted poll-based interfaces to native async ones, but actually
reorganized the worlds and changed some of the core abstractions. wasi:http
now exposes two worlds: wasi:http/service and wasi:http/middleware:
interface client { /* ... */ }
interface handler { /* ... */ }
// When used by guest bindings generators, grant the
// ability to make HTTP calls through the `client` import, and
// handle incoming HTTP requests through the `handler` export.
world service {
import client;
export handler;
}
// The middleware world is a super-set of the service world.
world middleware {
include service; // ← Do everything that `service` can do.
import handler; // ← But also pass incoming requests down to another handler.
}
The middleware world replaces the 0.2-era proxy world, and is used to define
HTTP handlers which can forward requests to other handlers. What’s new in WASI
0.3 is that this can now perform service
chaining:
a pattern where components can be directly composed with one another. This means
components acting as microservices that frequently interop with other
microservices, do not need to go over the network. Instead a runtime can choose
to directly compose them with each other inside the same process. For most
microservices this will reduce the time for calling other microservices from milliseconds to nanoseconds: six orders of magnitude.
We’re happy to share that WASI 0.3 has been released. That means that:
The best place to get started with WebAssembly Components is the Wasm Component Model book. For a comprehensive list of changes, see the WASI 0.3.0 release notes. If you’re wondering what’s next for WebAssembly Components and WASI, see The Road to Component Model 1.0.
WASI 0.3 is the work of a community. Thank you to everyone in the WASI Subgroup who designed, debated, and refined this release, to the runtime and toolchain maintainers who built the implementations that make it real, and to every contributor who filed an issue, reviewed a PR, or asked the hard question that made the spec better. And thank you to the users building on WASI; your components, your feedback, and your willingness to try release candidates shaped what shipped.
Component Model’s native async was years in the making, and it opens a new chapter: one where async and composability are first-class, and where the same primitives serve every language. We can’t wait to see what you build on it. Welcome to WASI 0.3.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。