WASI 0.3 poll-oneoff 移除与异步运行时迁移策略

WASI 0.3.0 于 2026 年 6 月 11 日发布，标志着 WebAssembly 系统接口进入原生异步时代。最显著的破坏性变更是彻底移除了 poll-oneoff 轮询模型，取而代之的是基于 Component Model 的 stream<T> 和 future<T> 资源抽象。这一变更不仅影响 WASI 接口本身，更对构建在之上的异步运行时（如 tokio、async-std 的 WASM 后端）提出了迁移要求。

WASI 0.2 轮询模型的局限

WASI 0.2 采用 readiness-based 轮询机制，核心由 Pollable 类型和 poll 函数构成。开发者需要为每个异步操作创建 pollable 句柄，通过 poll_oneoff 批量提交等待，再匹配返回索引到具体句柄提取结果。这种模型存在三个结构性问题：

并发瓶颈：poll_oneoff 一次只能处理一个就绪事件，高并发场景下需要反复轮询，形成线性扫描开销。Yoshua Wuyts 在构建 WASI 0.2 异步运行时的实践中发现，这种 "等待 - 匹配 - 提取" 的循环使得 I/O 密集型工作负载难以扩展。

资源膨胀：以 wasi:http 为例，0.2 版本需要 11 个资源类型来处理异步 HTTP 请求，每个请求涉及多次 pollable 注册与注销。资源管理复杂度随并发量线性增长。

语义鸿沟：pollable 模型要求开发者手动维护状态机，将高级语言的 async/await 语义降级为底层轮询操作。这种 "语法糖下的回调地狱" 增加了运行时实现的复杂度。

WASI 0.3 的 stream/future 资源模型

WASI 0.3 将 wasi:io 包整体移除，其功能被吸纳进 Component Model 的 Canonical ABI。新模型引入两类核心抽象：

stream<T> 表示有序、可流式传输的数据序列，支持背压（backpressure）和零拷贝传输；future<T> 表示异步计算的最终结果，对应传统 async/await 中的 Future 概念。两者均作为一等类型在 ABI 层实现，而非语言层面的语法糖。

WIT 接口定义语法随之更新：

// WASI 0.3 原生异步函数定义
interface key-value {
  get: async func(key: string) -> result<string, error>;
}

interface http {
  handle: async func(request: incoming-request) -> outgoing-response;
}

这种设计的优势在于运行时透明性 ——Rust、JavaScript、Python 等语言的异步代码通过 Canonical ABI 的 lifting/lowering 机制映射到同一底层表示，实现真正的多语言异步互操作。

运行时迁移策略

对于维护 tokio、smol、Monoio 等异步运行时的开发者，迁移需分三阶段推进：

阶段一：识别 poll-oneoff 依赖点

扫描代码库中所有 wasi::io::poll::poll 调用和 Pollable 类型使用。典型的迁移热点包括：

• 异步 I/O 等待逻辑（socket read/write、文件操作）
• 定时器实现（subscribe_duration 相关代码）
• HTTP 客户端 / 服务器的请求 / 响应处理

阶段二：重构为 async/await 模式

将 readiness-based 的 "注册 - 轮询 - 提取" 流程替换为 await 表达式。以 HTTP 请求为例：

// WASI 0.2 模式：手动轮询
let res = handle(req, None)?;
let pollable = res.subscribe();
poll::poll(&[&pollable]);
let response = res.get()?.unwrap()?;

// WASI 0.3 模式：原生 await
let response = handle(req).await?;

阶段三：适配 stream/future 资源生命周期

新模型要求运行时管理 stream 和 future 资源的创建、传输与关闭。关键变更点：

• 使用 stream<T> 替代字节流，支持结构化数据传输（如 stream<log-entry>）
• 通过 Canonical ABI 的内置函数实现流转发（forwarding/splicing）和零拷贝优化
• 处理取消（cancellation）语义，0.3.x 后续版本将集成语言级取消令牌

兼容性保障方案

WASI 0.3 的破坏性变更要求生态提供平滑迁移路径。Bytecode Alliance 推荐两种兼容性策略：

双版本运行时支持

Wasmtime 43+ 和 jco 选择同时支持 P2 和 P3。实现方式包括：

• 条件编译或运行时特性开关区分版本逻辑
• 维护两套 WASI 接口实现，通过组件版本元数据自动路由

P2 到 P3 虚拟化层

更轻量的方案是用 P3 原语 polyfill P2 接口。例如，将 poll_oneoff 实现为内部维护一个 future 集合，通过 await 等待任一完成后再模拟旧版索引返回。这种方式允许旧组件在新运行时上无需重新编译即可运行，但会引入轻微性能开销。

对于应用开发者，迁移检查清单包括：

1. 升级工具链至 wasm-tools 1.300+、wit-bindgen 0.40+
2. 使用 cargo component build 重新编译组件，目标指定为 WASI 0.3
3. 运行时启用 --wasip3 和 --component-model-async 标志
4. 验证取消语义和流边界处理是否符合预期

未来演进方向

WASI 0.3.x 系列将在发布列车模型下持续迭代，已规划的特性包括：流优化内置函数（forwarding、splicing、skip/write-zeroes）、调用方提供的缓冲区（caller-supplied buffers）进一步减少拷贝，以及从协作式到抢占式的线程支持。WASI 1.0 预计于 2026 年底至 2027 年初达到生产稳定状态。

poll-oneoff 的移除是 WASI 向生产级服务器端运行时迈进的关键一步。虽然迁移涉及破坏性变更，但 stream/future 模型消除了异步 I/O 的语义鸿沟，使 WebAssembly 组件能够与容器化工作负载在并发效率上竞争。对于运行时维护者，尽早适配新模型意味着在 1.0 生态中占据先发优势。

参考来源

• WASI Roadmap：WASI P3 发布说明与后续规划
• Designing an Async Runtime for WASI 0.2：Yoshua Wuyts 对 0.2 轮询模型的深度解析
• WASI 0.3 Native Async: WebAssembly Gets Concurrent I/O：stream/future 类型与性能对比分析

systems