wasmtime / issue #11590 Support accessing the store in `b... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #11590 Support accessing the store in `b...

Wasmtime GitHub notifications bot (Sep 02 2025 at 17:58):

alexcrichton opened issue #11590:

The bindgen! macro was redesigned in https://github.com/bytecodealliance/wasmtime/pull/11328 to have a more flexible configuration of imports/exports/flags. One of the motivations for doing this was to expose the concept of store as a flag on imported functions. Component-model-async imports, for example, get access to the store plus get to be async through the Accessor type. This is a pretty powerful feature compared to what we had prior where you only get &self or &mut self. While using self is more ergonomic it loses expressive power because the store can't be used during the import.

With #11328 it's now possible to say this through a flag where imports: { default: store } in theory means "all imports have access to the Store". Currently, however, this is unimplemented and just panics. The purpose of this issue is to track the implementation of this feature and serve as a discussion point for it.

In my head what I was thinking is something along the lines of:

Currently "foo": async and "foo": async | store works.

Currently nothing works and "foo": store does not work. This issue is about fixing that.

When using async | store a HostWithStore trait is created. Functions are defined as async fn in Rust and the store is provided as an &Accessor<...>

With using just store my thinking is that it should also put the function in the HostWithStore trait. The function signature would be just a plain fn and it would take an Access<...> (not an Accessor<...>)

This will require one of two routes. I've no preference to which:

"foo": store will require the component-model-async feature

The Access and Accessor types need to not be gated by component-model-async

After all this the idea then is that "foo": store is a valid and supported configuration. Hosts then implement HostWithStore and the Access provides access to &mut self just as it does today but it additionally provides access to the StoreContextMut<T> through the AsContextMut implementation.

Wasmtime GitHub notifications bot (Sep 02 2025 at 17:58):

alexcrichton added the wasmtime:api label to Issue #11590.

Wasmtime GitHub notifications bot (Sep 02 2025 at 17:58):

alexcrichton added the wasm-proposal:component-model label to Issue #11590.

Wasmtime GitHub notifications bot (Sep 02 2025 at 20:36):

fuzing commented on issue #11590:

Hi Alex -

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

Can you tell me whether the planned implementation outlined in this issue might help me with this - or whether there's another way to achieve my objective (i.e. getting access to the store from the expensivefunction implementation?

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 02 2025 at 20:38):

fuzing edited a comment on issue #11590:

Hi Alex -

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

Unfortunately, I can't see a way to add the store to my state because it appears to be non-clonable.

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 02 2025 at 20:44):

fuzing edited a comment on issue #11590:

Hi Alex -

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

We're currently using wasmer and are hoping to move to wasmtime - the mechanism I'm attempting above is used to inject the store into one's state for wasmer's embedding, but wasmer's store is behind an Arc<Mutex> so the Arc can be cloned and the mutex unlocked when contention free access is desired.

Unfortunately with wasmtime, I can't see a way to add the store to my state because it appears to be non-clonable.

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 02 2025 at 20:47):

fuzing edited a comment on issue #11590:

Hi Alex -

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

We're currently using wasmer and are hoping to move to wasmtime - the mechanism I'm attempting above is used to inject the store into one's state for wasmer's embedding, but wasmer's store is behind an Arc-Mutex so a clone().unlock() can be used for contention free access.

Unfortunately with wasmtime, I can't see a way to add the store to my state because it appears to be non-clonable.

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 02 2025 at 22:19):

fuzing edited a comment on issue #11590:

Hi Alex (@alexcrichton ) -

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

We're currently using wasmer and are hoping to move to wasmtime - the mechanism I'm attempting above is used to inject the store into one's state for wasmer's embedding, but wasmer's store is behind an Arc-Mutex so a clone().unlock() can be used for contention free access.

Unfortunately with wasmtime, I can't see a way to add the store to my state because it appears to be non-clonable.

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 03 2025 at 00:15):

fuzing edited a comment on issue #11590:

Hi Alex (@alexcrichton ) -

Our wasmtime embedding is required to be strictly deterministic, and hence all component functions are synchronous. I'm hoping this issue may address our need to avail our host implemented component functions with a mutable reference to the store.

I have a rust embedded wasmtime that's utilizing components and has a wit file as follows:

package abc:runtime@0.1.0;

interface functions {
   expensivefunction: func();

   // other function definitions here
}

world with-imports {
  import functions;
}

I would like to implement the expensivefunction function such that it has access to the store (potentially through my custom state):

struct CustomState {
    name: String,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {
    fn expensivefunction(&mut self) {
        // need access to my store here........ see below for details
    }


    // other function implementations go here

}

I've spent a good while attempting to add (a clone of) my store to my state, such that expensivefunction has access to the store - e.g. something like:

struct CustomState {
    name: String,
    // adding the store to state
    store: Option<Store<CustomState>>,
}

bindgen!({
    path: "wit",
    world: "with-imports",
});

impl abc::runtime::functions::Host for CustomState {

    fn expensivefunction(&mut self) {
        // we want this function to 'burn fuel' because it's expensive to run, so we'd like access to our store

        // can safely unwrap option because we know it's set up prior to anyone calling
        let store = self.store.unwrap();
        let current_fuel = store.get_fuel().expect("cannot get fuel");

        // set_fuel doesn't tolerate underflow, so make sure we don't do that!
        let actual_charge = std::cmp::min(current_fuel, 100_000);

        store.set_fuel(current_fuel - actual_charge).expect("error setting fuel");

        //
        // do expensive things after accounting for it by burning 100_000 worth of fuel
        //
    }


    // other function implementations go here

}


fn init() -> anyhow::Result<()> {
   ..
   ..
   //
   // prior to this line is boilerplate to set up the wasmtime engine with the appropriate options
   //

    let mut state = CustomState {
        name: "hello".to_string(),
        // we don't have a store yet, so set to None for now
        store: None,
    };

    let program_bytes = std::fs::read("target/wasm32-unknown-unknown/release/wasm_component.wasm")?;
    let wasm_component = Component::from_binary(&engine, &program_bytes)?;

    // Component Linker
    let mut linker = ComponentLinker::<CustomState>::new(&engine);


    let mut store = Store::new(&engine, state);
    store.set_fuel(FUEL_LIMIT)?;

    // this doesn't work - can't be cloned - how to access?
    state.store = Some(store.clone());


    // add the with imports component to the linker
    WithImports::add_to_linker::<_, HasSelf<_>>(&mut linker, |state| state)?;


     // below here is boilerplate to call a `run` function in our `wasm_component.wasm` component
     //  if/when this component's `run` function calls our hosted `expensivefunction` we'd like it to
     //  access the store and burn some extra fuel as demonstrated above
    ..
    ..
}

We're currently using wasmer and are hoping to move to wasmtime - the mechanism I'm attempting above is used to inject the store into one's state for wasmer's embedding, but wasmer's store is behind an Arc-Mutex so a clone().unlock() can be used for contention free access.

Unfortunately with wasmtime, I can't see a way to add the store to my state because it appears to be non-clonable.

Many thanks for a great project!

Wasmtime GitHub notifications bot (Sep 03 2025 at 19:06):

alexcrichton commented on issue #11590:

Makes sense, thanks for explaining. And yes, the feature described here should solve your use case. You'll be able to manipulate the store directly since your host function will be given one of these through which you can get StoreContextMut through which you can manipulate fuel.

Wasmtime GitHub notifications bot (Sep 03 2025 at 20:23):

fuzing commented on issue #11590:

Fantastic - thanks for the feedback. I'll be sure to put this through its paces once implemented. Cheers!

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:20):

alexcrichton closed issue #11590:

The bindgen! macro was redesigned in https://github.com/bytecodealliance/wasmtime/pull/11328 to have a more flexible configuration of imports/exports/flags. One of the motivations for doing this was to expose the concept of store as a flag on imported functions. Component-model-async imports, for example, get access to the store plus get to be async through the Accessor type. This is a pretty powerful feature compared to what we had prior where you only get &self or &mut self. While using self is more ergonomic it loses expressive power because the store can't be used during the import.

With #11328 it's now possible to say this through a flag where imports: { default: store } in theory means "all imports have access to the Store". Currently, however, this is unimplemented and just panics. The purpose of this issue is to track the implementation of this feature and serve as a discussion point for it.

In my head what I was thinking is something along the lines of:

Currently "foo": async and "foo": async | store works.

Currently nothing works and "foo": store does not work. This issue is about fixing that.

When using async | store a HostWithStore trait is created. Functions are defined as async fn in Rust and the store is provided as an &Accessor<...>

With using just store my thinking is that it should also put the function in the HostWithStore trait. The function signature would be just a plain fn and it would take an Access<...> (not an Accessor<...>)

This will require one of two routes. I've no preference to which:

"foo": store will require the component-model-async feature

The Access and Accessor types need to not be gated by component-model-async

After all this the idea then is that "foo": store is a valid and supported configuration. Hosts then implement HostWithStore and the Access provides access to &mut self just as it does today but it additionally provides access to the StoreContextMut<T> through the AsContextMut implementation.

Wasmtime GitHub notifications bot (Sep 05 2025 at 23:37):

fuzing commented on issue #11590:

Just tested this new functionality and it works like a charm.

One thing that might be of interest. Access is gated behind the component-model-async feature, which might not make sense any more.

Thank you so much for your effort here - it's much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Sep 07 2025 at 22:19):

alexcrichton reopened issue #11590:

The bindgen! macro was redesigned in https://github.com/bytecodealliance/wasmtime/pull/11328 to have a more flexible configuration of imports/exports/flags. One of the motivations for doing this was to expose the concept of store as a flag on imported functions. Component-model-async imports, for example, get access to the store plus get to be async through the Accessor type. This is a pretty powerful feature compared to what we had prior where you only get &self or &mut self. While using self is more ergonomic it loses expressive power because the store can't be used during the import.

With #11328 it's now possible to say this through a flag where imports: { default: store } in theory means "all imports have access to the Store". Currently, however, this is unimplemented and just panics. The purpose of this issue is to track the implementation of this feature and serve as a discussion point for it.

In my head what I was thinking is something along the lines of:

Currently "foo": async and "foo": async | store works.

Currently nothing works and "foo": store does not work. This issue is about fixing that.

When using async | store a HostWithStore trait is created. Functions are defined as async fn in Rust and the store is provided as an &Accessor<...>

With using just store my thinking is that it should also put the function in the HostWithStore trait. The function signature would be just a plain fn and it would take an Access<...> (not an Accessor<...>)

This will require one of two routes. I've no preference to which:

"foo": store will require the component-model-async feature

The Access and Accessor types need to not be gated by component-model-async

After all this the idea then is that "foo": store is a valid and supported configuration. Hosts then implement HostWithStore and the Access provides access to &mut self just as it does today but it additionally provides access to the StoreContextMut<T> through the AsContextMut implementation.

Wasmtime GitHub notifications bot (Sep 07 2025 at 22:19):

alexcrichton commented on issue #11590:

Yeah that's one where it's possible to ungate it outside of component-model-async but the feature is likely to be on-by-default in the near future so I figured it's fine to leave it there for now

Wasmtime GitHub notifications bot (Sep 07 2025 at 22:19):

alexcrichton closed issue #11590:

The bindgen! macro was redesigned in https://github.com/bytecodealliance/wasmtime/pull/11328 to have a more flexible configuration of imports/exports/flags. One of the motivations for doing this was to expose the concept of store as a flag on imported functions. Component-model-async imports, for example, get access to the store plus get to be async through the Accessor type. This is a pretty powerful feature compared to what we had prior where you only get &self or &mut self. While using self is more ergonomic it loses expressive power because the store can't be used during the import.

With #11328 it's now possible to say this through a flag where imports: { default: store } in theory means "all imports have access to the Store". Currently, however, this is unimplemented and just panics. The purpose of this issue is to track the implementation of this feature and serve as a discussion point for it.

In my head what I was thinking is something along the lines of:

Currently "foo": async and "foo": async | store works.

Currently nothing works and "foo": store does not work. This issue is about fixing that.

When using async | store a HostWithStore trait is created. Functions are defined as async fn in Rust and the store is provided as an &Accessor<...>

With using just store my thinking is that it should also put the function in the HostWithStore trait. The function signature would be just a plain fn and it would take an Access<...> (not an Accessor<...>)

This will require one of two routes. I've no preference to which:

"foo": store will require the component-model-async feature

The Access and Accessor types need to not be gated by component-model-async

After all this the idea then is that "foo": store is a valid and supported configuration. Hosts then implement HostWithStore and the Access provides access to &mut self just as it does today but it additionally provides access to the StoreContextMut<T> through the AsContextMut implementation.

Wasmtime GitHub notifications bot (Sep 07 2025 at 22:19):

alexcrichton commented on issue #11590:

er, wrong button

Wasmtime GitHub notifications bot (Sep 16 2025 at 13:44):

anlavandier commented on issue #11590:

Yeah that's one where it's possible to ungate it outside of component-model-async but the feature is likely to be on-by-default in the near future so I figured it's fine to leave it there for now

Hi, I would like to point out that the component-model-async is incompatible with no_std use cases so if it's possible to ungate Acess to use this with no_std it would be much appreciated.

Wasmtime GitHub notifications bot (Sep 16 2025 at 19:47):

alexcrichton commented on issue #11590:

Mind opening an issue for that?

Wasmtime GitHub notifications bot (Sep 17 2025 at 08:52):

anlavandier commented on issue #11590:

Mind opening an issue for that?

@alexcrichton did so, here's the issue #11705

Last updated: Dec 06 2025 at 07:03 UTC