Stream: wasi

Topic: How to add a HostFunction for WASI


view this post on Zulip Coulson Liang (Jun 13 2024 at 19:27):

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

view this post on Zulip Alex Crichton (Jun 13 2024 at 19:35):

Can you clarify what you mean by "HostFunction"?

view this post on Zulip Coulson Liang (Jun 13 2024 at 19:41):

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.

view this post on Zulip Joel Dice (Jun 13 2024 at 19:45):

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.

view this post on Zulip Coulson Liang (Jun 13 2024 at 20:04):

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.

view this post on Zulip Alex Crichton (Jun 13 2024 at 20:06):

Do you mean the implementations in the wasmtime-wasi crate?

view this post on Zulip Joel Dice (Jun 13 2024 at 20:06):

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.

view this post on Zulip Coulson Liang (Jun 13 2024 at 20:08):

Alex Crichton said:

Do you mean the implementations in the wasmtime-wasi crate?

Yeah yeah!

view this post on Zulip Coulson Liang (Jun 13 2024 at 20:08):

@Joel Dice Oh yeah, this makes perfect sense thanks!

view this post on Zulip Pat Hickey (Jun 13 2024 at 20:10):

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 .callfunctions to invoke wasmtime, async means you use .instantiate_async and .call_async which are async fn

view this post on Zulip Pat Hickey (Jun 13 2024 at 20:10):

(those being the methods on a Module or Component, and the instances)

view this post on Zulip Pat Hickey (Jun 13 2024 at 20:12):

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)

view this post on Zulip Pat Hickey (Jun 13 2024 at 20:13):

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

view this post on Zulip Coulson Liang (Jun 13 2024 at 20:34):

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