Stream: rfc-notifications

Topic: rfcs / Issue #11 RFC: Redesign Wasmtime's API

view this post on Zulip RFC notifications bot (May 06 2021 at 18:35):

acfoltzer commented on Issue #11:

I'm so excited about this, thank you for making it happen!

I'm a little unclear about the role of the store's type variable T from a library user perspective. I think it would help to have some examples of user code showing how the T impacts the developer experience. Is it usually going to be inferred or fixed by library code, or will the user have to reason about what this variable should be?

view this post on Zulip RFC notifications bot (May 06 2021 at 19:46):

alexcrichton commented on Issue #11:

A good question! It's sort of tangentially touched on here but the general idea is that if you are a library crate then to work with a Store<T> you'll probably place some sort of trait bound on T to get access to the data you'd want. For example with WASI:

// in the wasmtime-wasi crate
fn add_to_linker<T>(funcs: &mut Linker<'_, T>)
    where T: AsMut<WasiCtx>;

or alternatively:

// in your crate
fn add_to_linker<T>(
    funcs: &mut Linker<'_, T>,
    get: impl Fn(&mut T) -> &mut MyLibraryState + Copy + Send + Sync + 'static,
);

The idea being that the owner of the store will still determine the T for you. Libraries will work generically with some T with trait bounds or accessors or similar.

In terms of application code and such I'd imagine that the T is generally inferred from a call to Store::new for you, given that you're selecting some type to be owned by the store there.

view this post on Zulip RFC notifications bot (May 10 2021 at 16:53):

acfoltzer commented on Issue #11:

Hmm, I think I get it. To check my understanding, if I want to have my own application-specific context type but also a WASI context, how might that look? Create my own combined context type that impls both AsMut<WasiCtx> and AsMut<MyAppCtx>?

view this post on Zulip RFC notifications bot (May 10 2021 at 23:08):

alexcrichton commented on Issue #11:

@acfoltzer indeed! While it's not the prettiest this is an example in the branch I'm working on. The wasmtime CLI optionally supports some WASI proposals both at runtime and compile time, and that struct is used to manage the state where it's dynamically initialized and then used by linker-added functions through the BorrowMut traits

view this post on Zulip RFC notifications bot (May 10 2021 at 23:36):

acfoltzer commented on Issue #11:

Perfect, that makes tons of sense. Thank you!

Last updated: Dec 23 2024 at 13:07 UTC