Robin Freyler
Robin Freyler
This is due to the fact that in `wasmi` the `Engine` is used to allocate function signatures and constants as `EngineResources` instead of the Wasm `Store` for performance reasons. It...
As a work around what you could do is the following: You could resumably call the Wasm functions and instead of compiling a new Wasm module in a host function...
> As a work around what you could do is the following: > > You could resumably call the Wasm functions and instead of compiling a new Wasm module in...
There is another work around: Just do what `wasmi` version `0.13.0` (and older) did internally: Spin up a whole new `wasmi::Engine` for each new compiled Module. This would come with...
Cloning the `wasmi::Store` won't work because it would only do a shallow-copy of the associated `Engine` and therefore still use the same `wasmi::Engine` under the hood.
> Will it be the same if we do not intent to modify the resources of the Engine, for our specific use case? I viewed resources as the compiled functions,...
> Am I right to understand that all "static" states of instance will be in the Store? Yes, as per the Wasm specification the `Store` is the owner of all...
@lrubasze are you still in need of getting this fixed? I see the original PR was already merged.
> So maybe as an alternative you could add support for `Store` cloning? Since I want to stick as closely as possible to Wasmtime and Wasmtime's `Store` doesn't implement `Clone`...
@lrubasze If you are fine with the massive performance regressions introduced by [the PR](https://github.com/paritytech/wasmi/issues/682) then feel free to fork `wasmi` and merge the PR to fix your original issue. This...