Open sug0 opened 4 months ago
I think for the 2nd point (wrap_tx
and wrap_vp
) we could have something similar to the trait wasmer::HostFunction
that would call env.data_mut()
for us
on a second thought, it might be better to use wasmer::FunctionEnvMut
in our host_env directly in order to address 3rd point
on a second thought, it might be better to use
wasmer::FunctionEnvMut
in our host_env directly in order to address 3rd point
some functionality is mocked to run tests. wasmer
is not used in some calls to the host functions, so, unless we mock some kind of VmStore
that is used by the VmMemory
implementation, it is not advisable to pass FunctionEnvMut
to host functions directly
@cwgoes this shouldn't be consensus breaking, it doesn't change execution semantics, it's more of an internal detail (unless the vm is buggy)
In #3308,
wasmer
was bumped to 4.3.1. The migration from 2.x to 4.x came with significant API changes, which were addressed in a less than ideal way. Therefore, we ought to refactor/improve this code. Here are some of the associated tasks:Send
andSync
impls on wasm memory. We never share memory across threads, and it is not allocated in thread local storage; the only reason it is marked asSend
andSync
is to abide by the requirements ofwasmer
host functions, which must implementSend
andSync
.wrap_tx
andwrap_vp
modules.wasmer::Store
fromWasmMemory
. Instead, use the host function wrappers to grab awasmer::AsStoreMut
impl from thewasmer::FunctionEnvMut
.