Stream: git-wasmtime

Topic: wasmtime / PR #10016 wasmtime-wasi: Split a new `IoView` ...

Wasmtime GitHub notifications bot (Jan 14 2025 at 21:06):

pchickey opened PR #10016 from bytecodealliance:pch/wasi_view_traits to bytecodealliance:main:

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jan 14 2025 at 21:27):

pchickey updated PR #10016.

Wasmtime GitHub notifications bot (Jan 15 2025 at 00:27):

pchickey updated PR #10016.

Wasmtime GitHub notifications bot (Jan 15 2025 at 22:05):

pchickey updated PR #10016.

Wasmtime GitHub notifications bot (Jan 15 2025 at 22:06):

pchickey updated PR #10016.

Wasmtime GitHub notifications bot (Jan 16 2025 at 20:47):

pchickey edited PR #10016:

This PR prepares the wasi-io aspects of the wasmtime-wasi crate to be split off into its own independent crate, in order for the common base of wasi-io functionality to be reusable in a variety of host implementations which do not intend to reuse all of wasmtime-wasi.

Summary for users

You're using wasmtime-wasi, and maybe even wasmtime-wasi-http. You defined a struct like:

use wasmtime::component::ResourceTable;
use wasmtime_wasi::WasiCtx;
use wasmtime_wasi_http::WasiHttpCtx;
struct MyCtx {
    table: ResourceTable,
    wasi: WasiCtx,
    http: WasiHttpCtx,
}

Prior to this PR, you'd hook your MyCtx up to the WasiView and WasiHttpView traits like:

impl WasiView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi }
}
impl WasiHttpView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

After this PR, you rewrite that to:

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 }
}
impl WasiHttpView for MyCtx {
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

Thats it. For almost all users, you don't have to worry about anything else. All of the other aspects of wasmtime_wasi{,_http}::add_to_linker_{sync,async} keep working exactly like before. Semantically, nothing changed. The WasiView and WasiHttpView traits grew a common implies on the IoView trait, i.e. trait WasiView: IoView {...}, trait WasiHttpView: IoView {...}.

Wasmtime GitHub notifications bot (Jan 16 2025 at 20:53):

pchickey edited PR #10016:

This PR prepares the wasi-io aspects of the wasmtime-wasi crate to be split off into its own independent crate, in order for the common base of wasi-io functionality to be reusable in a variety of host implementations which do not intend to reuse all of wasmtime-wasi.

Summary for users

You're an embedder using wasmtime-wasi, and maybe even wasmtime-wasi-http. You defined a struct like:

use wasmtime::component::ResourceTable;
use wasmtime_wasi::WasiCtx;
use wasmtime_wasi_http::WasiHttpCtx;
struct MyCtx {
    table: ResourceTable,
    wasi: WasiCtx,
    http: WasiHttpCtx,
}

Prior to this PR, you'd hook your MyCtx up to the WasiView and WasiHttpView traits like:

impl WasiView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi }
}
impl WasiHttpView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

After this PR, you rewrite that to:

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 }
}
impl WasiHttpView for MyCtx {
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

Thats it. For almost all users, you don't have to worry about anything else. All of the other aspects of wasmtime_wasi{,_http}::add_to_linker_{sync,async} keep working exactly like before. Semantically, nothing changed. The WasiView and WasiHttpView traits grew a common implies on the IoView trait, i.e. trait WasiView: IoView {...}, trait WasiHttpView: IoView {...}.

More details

You probably don't care about these, unless you are doing low level linker stuff and probably can just read the source code to figure it out.

There's a new IoImpl struct that the wasi-io Host trait impls, instead of WasiImpl. Like WasiImpl this struct is #[repr(transparent)]. Anytime you were constructing a WasiImpl(t), you now construct WasiImpl(IoImpl(t)), e.g. https://github.com/bytecodealliance/wasmtime/pull/10016/files#diff-a6ec073ba5d074b65f0bcbf8df48af2b126d65034398905bf74d8f10a5c5f8b6R288

If you're using the wasmtime-wit-bindgen generated add_to_linker_ funcs directly, you'll need a variant on the type_annotate hack to get rustc to infer IoView in the right places, e.g. https://github.com/bytecodealliance/wasmtime/pull/10016/files#diff-a6ec073ba5d074b65f0bcbf8df48af2b126d65034398905bf74d8f10a5c5f8b6R287.

Wasmtime GitHub notifications bot (Jan 16 2025 at 20:53):

pchickey has marked PR #10016 as ready for review.

Wasmtime GitHub notifications bot (Jan 16 2025 at 20:53):

pchickey requested alexcrichton for a review on PR #10016.

Wasmtime GitHub notifications bot (Jan 16 2025 at 20:53):

pchickey requested wasmtime-core-reviewers for a review on PR #10016.

Wasmtime GitHub notifications bot (Jan 16 2025 at 21:45):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jan 16 2025 at 21:45):

alexcrichton created PR review comment:

These docs are now appended to the ones above, so should these words move above the example perhaps?

Wasmtime GitHub notifications bot (Jan 16 2025 at 21:45):

alexcrichton created PR review comment:

To perhaps bikeshed a bit, maybe TableView?

Wasmtime GitHub notifications bot (Jan 16 2025 at 21:45):

alexcrichton created PR review comment:

Also mind ensuring there's documentation for this trait as well? (similar to the WasiView one below)

Wasmtime GitHub notifications bot (Jan 16 2025 at 21:45):

alexcrichton created PR review comment:

Could this retain some of the documentation from before as well? Ideally with an example or links to other examples throughout the crate.

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:01):

pchickey submitted PR review.

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:01):

pchickey created PR review comment:

I named it Io instead of Table view in anticipation of factoring it out for the wasmtime-wasi-io crate. I don't mind renaming it, but thats why I was thinking Io over Table.

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:04):

pchickey submitted PR review.

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:04):

pchickey created PR review comment:

I made lots of fixes to the docs during the code motion for https://github.com/bytecodealliance/wasmtime/pull/10036 - can we put off the docs review and check it all over there?

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:07):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:07):

alexcrichton created PR review comment:

Sounds reasonable to me :+1:

Wasmtime GitHub notifications bot (Jan 16 2025 at 22:27):

alexcrichton merged PR #10016.

Last updated: Jan 24 2025 at 00:11 UTC