Looking Ahead to WASIp3
By: Joel Dice WebAssembly System Interface Preview 3 (or WASIp3 for short) is the next major release of WASI, a set of standards-track APIs for portable application development with WebAssembly. This release will include significant improvements to the underlying Component Model – including support for first class, composable concurrency – while maintaining compatibility with the existing WASIp2 release. In this post, we’ll summarize the new features coming with WASIp3, look at the status of the implementation efforts, and finally build a real-world example which puts those new features to use. About WASI and the WebAssembly Component Model WASI (WebAssembly System Interface) is a set of interfaces covering both traditional operating system features (e.g. file I/O, clocks, and networking) as well as more specialized features such as cloud services (HTTP, database access, messaging, etc.), abstractions for embedded systems, cryptography, etc. So far, WASI has had two milestone releases: 0.1 (AKA WASIp1, “Preview 1”) and 0.2 (AKA WASIp2, “Preview 2”). The latter was released early last year and was built upon the Component Model, a proposed standard for expressing the high-level interface of a Wasm application or library, enabling cross-language code reuse and secure dependency isolation. Before WASIp2 was even released, a few of us in the Bytecode Alliance were already prototyping the foundations of WASIp3, and we’ve made a lot of progress since then. Although there’s still significant work to do before it’s finally released later this year, we expect to start making release candidate snapshots available in the next couple of months, with experimental support for those snapshots landing in Spin and other popular runtimes soon after. These runtimes use WASI to provide a standardized environment for WebAssembly modules to interact with the host system. New Features in WASIp3 The main theme of WASIp3 is composable concurrency. Earlier releases support asynchronous I/O via a poll function which accepts a set of handles representing in-progress tasks, blocking until at least one of them completes. That works great for many purposes, but it makes composing components impractical when more than one of them need to do I/O concurrently; only one can call poll at a time, during which none of the others can make progress. In contrast, WASIp3 is based on two important new Component Model features: An asynchronous function ABI: This allows components to export and/or import functions using either the existing synchronous ABI or the new asynchronous ABI. Additionally, it avoids the function coloring problem by seamlessly connecting async imports to sync-exported functions and vice versa. Support for built-in, generic stream and future types, providing efficient, optionally asynchronous, cross-component and componenthost communication. Together, these features make concurrency a first-class concept in the component model, allowing arbitrary numbers of guest tasks to run concurrently in the same component instance. Moreover, components using the new async ABI may be composed with other components without risk of being blocked when one of those components makes a synchronous call. In that case, the host runtime will notice the blocking call, suspend the task that made it, and allow the original component to continue executing. Thanks to those new features, the WebAssembly Interface Types (WIT) definitions for 0.3 have been significantly simplified compared to their 0.2 counterparts. For example, while wasi:http@0.2.4 includes 11 distinct resource types, wasi:http@0.3.0-draft needs only 5. Similarly, the ceremony required to perform an asynchronous operation with WASIp2 – creating a pollable, adding it to a list along with anything else you intend to wait for, calling poll, and dispatching events according to which pollables are ready – has been replaced with a single call to an async function in your programming language of choice. WASIp3 Status The Component Model Specification includes a complete description of the async ABI, streams, futures, and associated built-in functions (look for the

By: Joel Dice
WebAssembly System Interface Preview 3 (or WASIp3 for short) is the next major release of WASI, a set of standards-track APIs for portable application development with WebAssembly. This release will include significant improvements to the underlying Component Model – including support for first class, composable concurrency – while maintaining compatibility with the existing WASIp2 release.
In this post, we’ll summarize the new features coming with WASIp3, look at the status of the implementation efforts, and finally build a real-world example which puts those new features to use.
About WASI and the WebAssembly Component Model
WASI (WebAssembly System Interface) is a set of interfaces covering both traditional operating system features (e.g. file I/O, clocks, and networking) as well as more specialized features such as cloud services (HTTP, database access, messaging, etc.), abstractions for embedded systems, cryptography, etc.
So far, WASI has had two milestone releases: 0.1 (AKA WASIp1, “Preview 1”) and 0.2 (AKA WASIp2, “Preview 2”). The latter was released early last year and was built upon the Component Model, a proposed standard for expressing the high-level interface of a Wasm application or library, enabling cross-language code reuse and secure dependency isolation.
Before WASIp2 was even released, a few of us in the Bytecode Alliance were already prototyping the foundations of WASIp3, and we’ve made a lot of progress since then. Although there’s still significant work to do before it’s finally released later this year, we expect to start making release candidate snapshots available in the next couple of months, with experimental support for those snapshots landing in Spin and other popular runtimes soon after. These runtimes use WASI to provide a standardized environment for WebAssembly modules to interact with the host system.
New Features in WASIp3
The main theme of WASIp3 is composable concurrency. Earlier releases support asynchronous I/O via a poll
function which accepts a set of handles representing in-progress tasks, blocking until at least one of them completes. That works great for many purposes, but it makes composing components impractical when more than one of them need to do I/O concurrently; only one can call poll
at a time, during which none of the others can make progress.
In contrast, WASIp3 is based on two important new Component Model features:
An asynchronous function ABI: This allows components to export and/or import functions using either the existing synchronous ABI or the new asynchronous ABI. Additionally, it avoids the function coloring problem by seamlessly connecting async imports to sync-exported functions and vice versa.
Support for built-in, generic
stream
andfuture
types, providing efficient, optionally asynchronous, cross-component and component<->host communication.
Together, these features make concurrency a first-class concept in the component model, allowing arbitrary numbers of guest tasks to run concurrently in the same component instance. Moreover, components using the new async ABI may be composed with other components without risk of being blocked when one of those components makes a synchronous call. In that case, the host runtime will notice the blocking call, suspend the task that made it, and allow the original component to continue executing.
Thanks to those new features, the WebAssembly Interface Types (WIT) definitions for 0.3 have been significantly simplified compared to their 0.2 counterparts. For example, while wasi:http@0.2.4
includes 11 distinct resource types, wasi:http@0.3.0-draft
needs only 5. Similarly, the ceremony required to perform an asynchronous operation with WASIp2 – creating a pollable
, adding it to a list along with anything else you intend to wait for, calling poll
, and dispatching events according to which pollable
s are ready – has been replaced with a single call to an async
function in your programming language of choice.
WASIp3 Status
The Component Model Specification includes a complete description of the async ABI, streams, futures, and associated built-in functions (look for the