Expand description
§Wasmtime’s WASIp2 Implementation
This module provides a Wasmtime host implementation of WASI 0.2 (aka WASIp2
aka Preview 2) and WASI 0.1 (aka WASIp1 aka Preview 1). WASI is implemented
with the Rust crates tokio
and cap-std
primarily, meaning that
operations are implemented in terms of their native platform equivalents by
default.
§WASIp2 interfaces
This module contains implementations of the following interfaces:
wasi:cli/environment
wasi:cli/exit
wasi:cli/stderr
wasi:cli/stdin
wasi:cli/stdout
wasi:cli/terminal-input
wasi:cli/terminal-output
wasi:cli/terminal-stderr
wasi:cli/terminal-stdin
wasi:cli/terminal-stdout
wasi:clocks/monotonic-clock
wasi:clocks/wall-clock
wasi:filesystem/preopens
wasi:filesystem/types
wasi:random/insecure-seed
wasi:random/insecure
wasi:random/random
wasi:sockets/instance-network
wasi:sockets/ip-name-lookup
wasi:sockets/network
wasi:sockets/tcp-create-socket
wasi:sockets/tcp
wasi:sockets/udp-create-socket
wasi:sockets/udp
All traits are implemented in terms of a WasiView
trait which provides
access to WasiCtx
, which defines the configuration for WASI.
The WasiView
trait imples IoView
, which provides access to a common
ResourceTable
, which owns all host-defined component model resources.
The wasmtime-wasi-io
crate contains implementations of the
following interfaces, and this module reuses those implementations:
These traits are implemented in terms of a IoView
trait, which only
provides access to a common ResourceTable
. All aspects of
wasmtime-wasi-io
that are used by this module are re-exported. Unless you
are implementing other host functionality that needs to interact with the
WASI scheduler and don’t want to use other functionality provided by
wasmtime-wasi
, you don’t need to take a direct dependency on
wasmtime-wasi-io
.
§Generated Bindings
This module uses wasmtime::component::bindgen!
to generate bindings for
all WASI interfaces. Raw bindings are available in the bindings
submodule
of this module. Downstream users can either implement these traits themselves
or you can use the built-in implementations in this module for
WasiImpl<T: WasiView>
.
§The WasiView
trait
This module’s implementation of WASI is done in terms of an implementation of
WasiView
. This trait provides a “view” into WASI-related state that is
contained within a Store<T>
. WasiView
implies the
IoView
trait, which provides access to common ResourceTable
which
owns all host-implemented component model resources.
For all of the generated bindings in this module (Host traits), implementations are provided looking like:
impl<T: WasiView> bindings::wasi::Host for WasiImpl<T> {
// ...
}
The add_to_linker_sync
and add_to_linker_async
function then require
that T: WasiView
with Linker<T>
.
To implement the WasiView
and IoView
trait you will first select a
T
to put in Store<T>
(typically, by defining your own struct).
Somewhere within T
you’ll store:
ResourceTable
- created through default constructors.WasiCtx
- created throughWasiCtxBuilder
.
You’ll then write implementations of the IoView
and WasiView
traits to access those items in your T
. For example:
use wasmtime::component::ResourceTable;
use wasmtime_wasi::p2::{WasiCtx, IoView, WasiView};
struct MyCtx {
table: ResourceTable,
wasi: WasiCtx,
}
impl IoView for MyCtx {
fn table(&mut self) -> &mut ResourceTable {
&mut self.table
}
}
impl WasiView for MyCtx {
fn ctx(&mut self) -> &mut WasiCtx {
&mut self.wasi
}
}
§Async and Sync
As of WASI0.2, WASI functions are not blocking from WebAssembly’s point of view: a WebAssembly call into these functions returns when they are complete.
This module provides an implementation of those functions in the host,
where for some functions, it is appropriate to implement them using
async Rust and the Tokio executor, so that the host implementation can be
nonblocking when Wasmtime’s Config::async_support
is set.
Synchronous wrappers are provided for all async implementations, which
creates a private Tokio executor.
Users can choose between these modes of implementation using variants of the add_to_linker functions:
- For non-async users (the default of
Config
), useadd_to_linker_sync
. - For async users, use
add_to_linker_async
.
Note that bindings are generated once for async and once for sync. Most interfaces do not change, however, so only interfaces with blocking functions have bindings generated twice. Bindings are organized as:
bindings
- default location of all bindings, blocking functions areasync
bindings::sync
- blocking interfaces have synchronous versions here.
§Module-specific traits
This module’s default implementation of WASI bindings to native primitives
for the platform that it is compiled for. For example opening a TCP socket
uses the native platform to open a TCP socket (so long as WasiCtxBuilder
allows it). There are a few important traits, however, that are specific to
this module.
-
InputStream
andOutputStream
- these are the host traits behind the WASIinput-stream
andoutput-stream
types in thewasi:io/streams
interface. These enable embedders to build their own custom stream and insert them into aResourceTable
(as a boxed trait object, seeDynInputStream
andDynOutputStream
) to be used from wasm. -
Pollable
- this trait enables building arbitrary logic to get hooked into apollable
resource fromwasi:io/poll
. A pollable resource is created through thesubscribe
function. -
HostWallClock
andHostMonotonicClock
are used in conjunction withWasiCtxBuilder::wall_clock
andWasiCtxBuilder::monotonic_clock
if the defaults host’s clock should not be used. -
StdinStream
andStdoutStream
are used to provide custom stdin/stdout streams if they’re not inherited (or null, which is the default).
These traits enable embedders to customize small portions of WASI interfaces provided while still providing all other interfaces.
§Examples
Usage of this module is done through a few steps to get everything hooked up:
- First implement
IoView
andWasiView
for your type which is theT
inStore<T>
. - Add WASI interfaces to a
wasmtime::component::Linker<T>
. This is either done through top-level functions likeadd_to_linker_sync
or through individualadd_to_linker
functions in generated bindings throughout this module. - Create a
WasiCtx
for eachStore<T>
throughWasiCtxBuilder
. Each WASI context is “null” or “empty” by default, so items must be explicitly added to get accessed by wasm (such as env vars or program arguments). - Use the previous
Linker<T>
to instantiate aComponent
within aStore<T>
.
For examples see each of WasiView
, WasiCtx
, WasiCtxBuilder
,
add_to_linker_sync
, and bindings::Command
.
Modules§
Structs§
- Async
Stdin Stream - An impl of
StdinStream
built on top ofcrate::p2::pipe::AsyncReadStream
. - Async
Stdout Stream - A wrapper of
crate::p2::pipe::AsyncWriteStream
that implementsStdoutStream
. Note that theOutputStream
impl for this is not correct when used for interleaved async IO. - DynPollable
- The host representation of the
wasi:io/poll.pollable
resource. - File
Input Stream - IoImpl
- A small newtype wrapper which serves as the basis for implementations of
Host
WASI traits in this crate. - Output
File - This implementation will yield output streams that block on writes, and
output directly to a file. If truly async output is required,
AsyncStdoutStream
should be used instead. - Stderr
- This implementation will yield output streams that block on writes, as they
inherit the implementation directly from the rust std library. A different
implementation of
StdoutStream
will be necessary if truly async output streams are required. - Stdin
- Only public interface is the
InputStream
impl. - Stdout
- This implementation will yield output streams that block on writes, as they
inherit the implementation directly from the rust std library. A different
implementation of
StdoutStream
will be necessary if truly async output streams are required. - WasiCtx
- Per-
Store
state which holds state necessary to implement WASI from this crate. - Wasi
CtxBuilder - Builder-style structure used to create a
WasiCtx
. - Wasi
Impl - A small newtype wrapper which serves as the basis for implementations of
Host
WASI traits in this crate.
Enums§
Traits§
- Input
Stream - Host trait for implementing the
wasi:io/streams.input-stream
resource: A bytestream which can be read from. - IoView
- A trait which provides access to the
ResourceTable
inside the embedder’sT
ofStore<T>
. - Output
Stream - Host trait for implementing the
wasi:io/streams.output-stream
resource: A bytestream which can be written to. - Pollable
- The trait used to implement
DynPollable
to create apollable
resource inwasi:io/poll
. - Stdin
Stream - A trait used to represent the standard input to a guest program.
- Stdout
Stream - Similar to
StdinStream
, except for output. - Wasi
View - A trait which provides access to the
WasiCtx
inside the embedder’sT
ofStore<T>
.
Functions§
- add_
to_ linker_ async - Add all WASI interfaces from this crate into the
linker
provided. - add_
to_ linker_ sync - Add all WASI interfaces from this crate into the
linker
provided. - add_
to_ linker_ with_ options_ async - Similar to
add_to_linker_async
, but with the ability to enable unstable features. - add_
to_ linker_ with_ options_ sync - Similar to
add_to_linker_sync
, but with the ability to enable unstable features. - stderr
- Returns a stream that represents the host’s standard err.
- stdin
- Returns a stream that represents the host’s standard input.
- stdout
- Returns a stream that represents the host’s standard out.
- subscribe
- Creates a
wasi:io/poll/pollable
resource which is subscribed to the providedresource
.
Type Aliases§
- DynFuture
- DynInput
Stream - DynOutput
Stream - FsError
- FsResult
- IoError
- Representation of the
error
resource type in thewasi:io/error
interface. - Make
Future - Socket
Error - Socket
Result - Stream
Result