Design discussion: host with access to &mut T in Store<T>

[Mossaka]

This is a follow-up question regarding why wit-bindgen does not generate host trait with access to Store<T>. @alexcrichton explained in a Zulip chat:

the wit-bindgen-generated bindings don't give you access to the store during the duration of host calls, but that's by design today to enable other optimizations.

I am wondering if it's possible to add mode/flag to wit-bindgen, which can modify generator's behaviors. For example, if the ExposeStore flag is set, then the generated host trait has access to Store<T>, or the &mut T. I've been implementing wasi-callback for the last week, and one of the key feature to enable callbacks, is to use AsContextMut struct and I found this to be extremely useful for managing the state of the Store.

I've modified the Rust bindings for wit_bindgen_gen_wasmtime:

1. The get() function takes a T and returns (Arc<Mutex<T>>, Arc<Mutex<ExecTables<T>>>)

pub fn add_to_linker<T: Exec>(
    linker: &mut wasmtime::Linker<T::Context>,
    get: impl Fn(&T::Context) -> (Arc<Mutex<T>>, Arc<Mutex<ExecTables<T>>>) + Send + Sync + Copy + 'static,
) -> anyhow::Result<()> 

2. I have the following WIT and modified the host trait:

resource events {
    static get: function() -> events
    exec: function(duration: u64) -> unit
}

pub trait Exec: Sized {
    type Context: Default;
    type Events: Default;
    fn events_get(&mut self, data: &mut Self::Context) -> Result<Self::Events, Error>;

    fn events_exec(
        &mut self,
        data: &mut Self::Context,
        self_: &Self::Events,
        duration: u64,
    ) -> Result<(), Error>;

    fn drop_events(&mut self, state: Self::Events) {
        drop(state);
    }
}

Notice how events_exec has a argument to &mut Self::Context. This allows me to store a guest handler function and invoke the handler function in runtime.

Discussion

Of course the way that I had to manually modify the generated code is not ideal. It increases maintainence burden, and it is not compatible with future breaking changes in WIT, especially if the WIT file changes often. This is why I hope the wit-bindgen could do this for me. Any thoughts?

[alexcrichton]

With further discussions on the component model, I don't think that your desired use case is going to be supported here. If I understand correctly you're implementing a host function which when called will call back synchronously into the original module. That is specifically disallowed by the may_enter and such flags in the component model, so even if access were granted you wouldn't actually be able to do anything with it.

[Mossaka]

Thanks @alexcrichton for the clarification!

That is specifically disallowed by the may_enter and such flags in the component model, so even if access were granted you wouldn't actually be able to do anything with it.

Could I get more insights into why this is disallowed? Is it due to optimization concerns or security concens, or something else?

[alexcrichton]

It's probably best to read over the wording at https://github.com/webassembly/component-model and if it doesn't feel justified still I'd recommend opening an issue about updating the justification and/or adding clarification.