WASI 0.3 released with native async support for WebAssembly Components

The WASI Subgroup has ratified the WASI 0.3.0 specification, which integrates asynchronous capabilities directly into the WebAssembly Component Model's canonical ABI. Unlike version 0.2, where each component required its own event loop, WASI 0.3 allows the host runtime to manage a single, shared event loop for all components. This change introduces first-class stream<T> and future<T> constructs and moves from a readiness-based to a completion-based async model.

Technical improvements in WASI 0.3

• Shared Event Loop: The host runtime manages scheduling, allowing components to coordinate via a single event loop rather than isolated runtimes.
• Completion-based Model: Uses a model similar to Linux io_uring and Windows IOCP, rather than readiness-based APIs like epoll/kqueue.
• New Primitives: Introduces stream<T> and future<T> as owned resource types within the canonical ABI.
• Improved Error Handling: Streams now return an independent future to resolve stream status, preventing errors from being missed if a reader stops early.
• Service Chaining: The updated wasi:http interface enables components to compose directly in-process, potentially reducing microservice communication latency from milliseconds to nanoseconds.

Why it matters

The release enables language binding generators to produce idiomatic async code for various languages (Rust, Go, Python, etc.) and allows microservices to interoperate within a single process without network overhead.