Crate wasi_cap_std_sync

Expand description

The wasi-cap-std-sync crate provides impl of WasiFile and WasiDir in terms of cap_std::fs::{File, Dir}. These types provide sandboxed access to the local filesystem on both Unix and Windows.

All syscalls are hidden behind the cap-std hierarchy, with the lone exception of the sched implementation, which is provided for both unix and windows in separate modules.

Any wasi_common::{WasiCtx, WasiCtxBuilder} is interoperable with the wasi-cap-std-sync crate. However, for convenience, wasi-cap-std-sync provides its own WasiCtxBuilder that hooks up to all of the crate’s components, i.e. it fills in all of the arguments to WasiCtx::builder(...), presents preopen_dir in terms of cap_std::fs::Dir, and provides convenience methods for inheriting the parent process’s stdio, args, and env.

For the convenience of consumers, cap_std::fs::Dir is re-exported from this crate. This saves consumers tracking an additional dep on the exact version of cap_std used by this crate, if they want to avoid it.

The only place we expect to run into long-term compatibility issues between wasi-cap-std-sync and the other impl crates that will come later is in the Sched abstraction. Once we can build an async scheduler based on Rust Futures, async impls will be able to interoperate, but the synchronous scheduler depends on downcasting the WasiFile type down to concrete types it knows about (which in turn impl AsFd for passing to unix poll, or the analogous traits on windows).

Why is this impl suffixed with -sync? Because async is coming soon! The async impl may end up depending on tokio or other relatively heavy deps, so we will retain a sync implementation so that wasi-common users have an option of not pulling in an async runtime.