Jeff Charles (Mar 12 2025 at 18:15): Jeff Charles (Mar 12 2025 at 18:15):Is there way to configure a wasmtime-wasi WASI context such that a call to sleep or an equivalent operation in a Wasm instance returns immediately?
The context is we have a platform where we expect third-party modules to run for very short periods of time and would not have a valid reason to sleep. We impose a strict fuel limit on instances but have a more generous time-based limit to not trigger user or developer-facing errors when there's CPU contention. With wasi-common's WasiCtx, I could provide my own WasiSched implementation but that doesn't appear to be configurable in wasmtime-wasi.
Pat Hickey (Mar 12 2025 at 18:17):wasmtime-wasi is really not designed to be configured in that manner.
Pat Hickey (Mar 12 2025 at 18:17):however, you can compose your own wasi implementation reusing some pieces of wasmtime-wasi (via add_to_linker_get_host) and some pieces of your own
Pat Hickey (Mar 12 2025 at 18:18):in this case you'd want to just provide your own impl of the wasi::clocks::...::Host traits, and for the Pollable implementation returned by the subscribe functions it would just have async fn ready(&self) {}
Pat Hickey (Mar 12 2025 at 18:19):so you could copy-paste the implementations of those clocks traits from wasmtime-wasi into your own crate, change enough identifiers that it compiles, and then basically erase the tokio::time::sleep(whatever).await in those ready funcs
Last updated: Apr 08 2025 at 10:03 UTC