WASI 0.3が安定版に、WebAssemblyコンポーネントの非同期処理が共通基盤へ
WASI 0.3が安定版に、WebAssemblyコンポーネントの非同期処理が共通基盤へ
Bytecode Allianceは6月中旬、WebAssembly System Interfaceの最新仕様であるWASI 0.3の安定版公開を発表した。Publickeyも6月15日にこの更新を取り上げ、WebAssemblyコンポーネントの非同期処理が共通化された点を大きな 変更点として伝えた。
Bytecode Alliance announced the stable release of WASI 0.3, the latest WebAssembly System Interface specification, in mid-June. Publickey also covered the update on June 15 and highlighted shared async handling for WebAssembly components as the main change.
公式記事によると、WASI 0.3はWASI Subgroupの投票を通過した安定版で、いまコンパイルしたプログラムは将来も動作継続するよう保証されると説明されている。破壊的変更を頻繁に受ける 実験段階から、長く 使える 仕様へ移ったことになる。
According to the official announcement, WASI 0.3 passed a WASI Subgroup vote as a stable release, and programs compiled for it now are guaranteed to keep working in the future. That shifts it from an experimental stage toward a specification developers can build on for longer periods.
何が変わったのか
最大の焦点は、Component Modelに非同期の仕組みが正式 入ったことだ。Bytecode Allianceは、WASI 0.3で`async func`、`stream<T>`、`future<T>`のような基本要素が土台に加わったと説明している。
The main change is that the Component Model now includes async as an official mechanism. Bytecode Alliance says WASI 0.3 adds foundational elements such as `async func`, `stream<T>`, and `future<T>`.
これまでのWASI 0.2では、各コンポーネントがそれぞれの事象待機の流れを持つ 形になりやすく、別のコンポーネントどうしを組み合わせるときに実行環境側の工夫が必要だった。WASI 0.3では、ホストが一つの共通イベントループを管理し、複数コンポーネントを同じ基盤で扱えるようになった。
Under WASI 0.2, each component tended to bring its own event-loop flow, so composing different components often required runtime-side workarounds. In WASI 0.3, the host manages one shared event loop and can handle multiple components on the same foundation.
開発者にとっての意味
この変更が重要なのは、言語や実装ごとに異なる 非同期モデルを接続しやすくするからだ。Bytecode Allianceは、同じ原始機能がRust、Go、JavaScript、Pythonなどにまたがって使われる 方向を示した。
The change matters because it makes it easier to connect async models that differ by language and implementation. Bytecode Alliance presents it as a direction where the same primitive capabilities can be used across Rust, Go, JavaScript, Python, and more.
Publickeyの整理でも、以前は個別コンポーネントごとの非同期APIが混ざりにくかったのに対し、WASI 0.3では相互接続が容易になったと説明されている。つまり、多言語のWasmシステムを組むときの面倒が、仕様レベルで減ることになる。
Publickey's summary also says that where per-component async APIs used to be hard to mix, WASI 0.3 makes interconnection easier. In practice, that reduces some of the friction of assembling multi-language Wasm systems at the specification level.
周辺実装はどう動くか
公式記事では、Wasmtime 45がすでに最新リリース候補版を実行でき、Wasmtime 46ではWASI 0.3.0が初期設定で有効化される予定だとされる。JavaScript向けツールチェーンのjcoも追随していると案内された。
The official article says Wasmtime 45 can already run the latest release candidate, and Wasmtime 46 is expected to enable WASI 0.3.0 by default. It also notes that the JavaScript-focused jco toolchain is following behind.
一方で、言語向けの対応はまだ広がる 途中だ。Bytecode Allianceは、今後Rust、Go、JavaScript、Pythonなどのゲスト向けツールチェーンでもWASI 0.3の採用が進むと見ているが、この部分は段階的に進むと読んだほうがよさそうだ。
At the same time, support across language toolchains is still expanding. Bytecode Alliance expects WASI 0.3 adoption to spread across guest-side toolchains such as Rust, Go, JavaScript, and Python, but this part still looks likely to roll out step by step.
この先にあるもの
Bytecode Allianceは別記事「The Road to Component Model 1.0」で、次の目標をComponent Model 1.0に置いた。そこではABIの改善、複数ブラウザ実装、より簡単な組み込みなどが課題として挙げられている。
In a separate article, "The Road to Component Model 1.0," Bytecode Alliance sets the next target as Component Model 1.0. It lists ABI improvements, multiple browser implementations, and easier embedding as the work ahead.
今回のWASI 0.3は、WebAssemblyが「実験的で面白い」段階から、言語横断の部品接続を現実的に設計する段階へ進んだことを示す 節目だ。実行環境や開発基盤を作るエンジニアほど、この安定化の意味を重く 見ることになりそうだ。
WASI 0.3 marks a step where WebAssembly moves beyond being merely interesting and becomes more practical for designing cross-language component composition. The engineers most likely to care are the ones building runtimes and development platforms.