78 个版本 (47 个稳定版)
| 17.0.3 | 2024 年 4 月 11 日 |
|---|---|
| 17.0.2 | 2024 年 2 月 28 日 |
| 17.0.0 | 2024 年 1 月 25 日 |
| 16.0.0 | 2023 年 12 月 20 日 |
| 0.25.0 | 2021 年 3 月 16 日 |
1565 在 WebAssembly 中
24,178 每月下载量
用于 31 个 Crates（直接使用 5 个）
310KB
7.5K SLoC
使用 cap-std 的 Rust 中的 WASI 实现。
lib.rs:
该 wasi-cap-std-sync 包提供了 WasiFile 和 WasiDir 的实现，这些类型以 cap_std::fs::{File, Dir} 的形式存在。这些类型提供了对 Unix 和 Windows 上本地文件系统的沙盒访问。
所有系统调用都隐藏在 cap-std 层级之后，唯一的例外是 sched 实现，它以单独的模块分别提供给 Unix 和 Windows。
任何 wasi_common::{WasiCtx, WasiCtxBuilder} 都与 wasi-cap-std-sync 包兼容。但是为了方便，wasi-cap-std-sync 提供了自己的 WasiCtxBuilder，该构建器与包的所有组件连接，即填充 WasiCtx::builder(...) 的所有参数，以 cap_std::fs::Dir 的形式提供 preopen_dir，并提供方便的方法来继承父进程的 stdio、args 和 env。
为了方便消费者，cap_std::fs::Dir 从这个包中重新导出。这样，如果消费者想要避免它，就不需要追踪此包使用的 cap_std 的确切版本。
我们预计在 wasi-cap-std-sync 和未来将出现的其他实现crate之间可能遇到长期兼容性问题的地方是 Sched 抽象。一旦我们可以基于 Rust Future 构建异步调度器，异步实现将能够相互操作，但同步调度器依赖于将 WasiFile 类型下转换为已知的具体类型（这反过来实现了 AsFd 以传递给 Unix poll，或者 Windows 上的类似特质）。
为什么这个实现以 -sync 结尾？因为异步（async）即将到来！异步实现最终可能依赖于 tokio 或其他相对较重的依赖，因此我们将保留同步实现，以便 wasi-common 用户有选择不引入异步运行时的选项。
依赖项
~17–29MB
~464K SLoC