Store and FunctionEnv design questions

[ValeryAntopol]

Summary

I am currently implementing a generic wasm backend interface and its implementations for Wasmer and Wasmtime, to be able to easily switch between wasm backends. Such a task forces me to compare APIs of wasm engines, and in result I have a couple of questions for Wasmer.

1. Why Store does not allow to store user-defined type?

Wasmtime allows to store arbitrary type (even without Send + Sync requirements!), and allows access to it in their StoreMut/StoreRef analogue. Wasmer allows the same only with FunctionEnv, so if I want to give such option to the user, I need to have a store-wrapper done in a way like this:

struct WasmerStore<T: Any + Send + Sized + 'static> {
  store: wasmer::Store,
  user_data: wasmer::FunctionEnv<T>, 
}

Or do all the low-level unsafe stuff that Wasmer does under the hood. And it looks weird, using a FunctionEnv when there are no functions.

2. Why there is no access to the calling instance in host imports?
   As I found in docs and issues, the only way to get access to module exports from inside host import is passing them through FunctionEnv by hand How to use memory in version 3.0 #3113, How to handle imported memory in an import function? #3444 . This forces the user to keep track on the created FunctionEnv objects and to put necessary handles in them before calling. This works well in a single-instance scenario, but makes handling multiple instances difficult. There are more concerns about it, in How to get memory in an import function in 3.0 for multiple instances? #3359, Added Attach/Detach instance from a FunctionEnv (allow use of Instance from a function callback) #3283, Discuss / Decide a nice API to allow Context to do things on instance instantiation #2924

It can be done by passing not just FunctionEnvMut<T> to functions, but a larger structure Calller<T>. That structure can allow accessing both FunctionEnvMut<T> and Option<TemporaryInstanceHandle>, so function will always be able to access exports, no matter what instance called it. Of course it will be None in case of direct call from host, but that should not be a problem.

[syrusakbary]

Why Store does not allow to store user-defined type?

Stores should be generic over the type used in the functions inside of it, it keeps the abstractions much simpler.
IMO there are only two kinds of stores: A Store that have function envs that can be Send+Sync (So the Store is Send+Sync itself) and Store that is not.
Wasmer pushes the responsibility of the data types into the FunctionEnvs instead of Store, because that makes it way easier to reason about them.

Why there is no access to the calling instance in host imports?

Our API is heavily inspired by the JS API. It was intentional not having the calling instance in the host imports, because it introduces leaky abstractions all over the API (for example, it allows users to not precompute the used imports that may be accessed by the function, and just be lazy and fetch it constantly at runtime). That abstraction also fulfills fully the requirements for the wasm-c-api without adding some extra layers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Feel free to reopen the issue if it has been closed by mistake.