How would I use get_remaining_points and set_remaining_points in wasmer-wasix? And does metering work with multiple threads?

[newclarityex]

get_remaining_points/set_remaining_points requires an Instance, which I don't have when using run_wasm in wasmer-wasix.

[KirilsTurkins]

WasiRunner::run_wasm does not currently expose the Store or Instance. It builds the WASIX environment, transfers the module and environment to spawn_exec_module, and returns only Result<()>. The resulting instance is owned by the internal WASIX task, so get_remaining_points and set_remaining_points cannot be used externally with that API.

If the goal is only to enforce a fixed execution limit, configuring Metering::new(initial_limit, cost_function) during module compilation is sufficient. The instrumented module will trap when the limit is exhausted, even when executed through run_wasm.

If the remaining balance must be inspected or reset, the current public workaround is to avoid run_wasm and instantiate through WasiEnvBuilder::instantiate or instantiate_ext, retaining the returned Instance and the caller-owned Store:

let (instance, wasi_env) =
    WasiEnv::builder("app").instantiate(module, &mut store)?;


let remaining = get_remaining_points(&mut store, &instance);
set_remaining_points(&mut store, &instance, new_limit);

The application would then need to run the module through that lower-level setup. For simple WASI modules, calling _start directly may be sufficient. For full WASIX behavior, this is not equivalent to WasiRunner::run_wasm, since the runner also manages bootstrap, context switching, suspension and resumption, process handling, and cleanup.

Therefore, dynamically observing or replenishing the meter while retaining the complete run_wasm execution path appears to require a new runner hook or API. Such a hook would likely need to execute on the task that owns the Store, rather than merely returning a cross-thread Instance.