Hi, I'm playing with my own wasm libc, and want to add a new HostFunction to maybe wasi_snapshot_preview1
for testing purpose. What are the steps should be taken?
Seems like I need to change wasi_snapshot_preview1.witx
and also update these two lists?
image.png
Can you clarify what you mean by "HostFunction"?
Oh sorry, I just mean functions like fd_write
and path_open
, the functions provisioned by the runtime and can be imported in the wasm module.
You'll probably want to use https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html#method.func_wrap. I'd recommend not using the wasi_snapshot_preview1
namespace for new functions not defined as part of WASIp1. Instead, just make up your own module name, like nyu_wasm_experiment
or whatever.
Thanks, will go with that. Btw, why in the source code of preview1, all the fd_write
path_open
functions are "async"? I thought these IO operations are usually to be blocking by default.
Do you mean the implementations in the wasmtime-wasi
crate?
Functions like fd_write
should block the guest but not block the host. So wasmtime-wasi
makes them async, allowing the fd_write
implementation to yield and allow the host to do other work while the write is happening.
Alex Crichton said:
Do you mean the implementations in the
wasmtime-wasi
crate?
Yeah yeah!
@Joel Dice Oh yeah, this makes perfect sense thanks!
basically the two functions add_to_linkers_{sync,async} expose the exact same host functionality to two different ways of using the wasmtime engine - if you use the sync option, that means you use plain old .instantiate
and .call
functions to invoke wasmtime, async means you use .instantiate_async
and .call_async
which are async fn
(those being the methods on a Module or Component, and the instances)
but internally, the host functions that the wasm calls out to are fundamentally async rust. if you use them from a sync context, the sync add_to_linker just performs a little wrapping that uses an ambient tokio runtime to block_on
, which takes an async fn
and executes it as a fn
(to a first approximation)
this is my hobby horse, that the whole crux of wasi is scheduling, because it was hard and i worked on it for way too long. you probably dont have to care about it
Yeah thank you for the details. I see, the options depends on if we want to use wasmtime engine synchronously or not. And to the _guest_, i.e. the caller wasm module, these are all blocking.
Last updated: Dec 23 2024 at 13:07 UTC