You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to support Wasmer 3 in fp-bindgen. However, Wasmer 3 brings with a few changes that make it less than trivial to upgrade to it. This caused our initial upgrade approach to fizzle out, but some lessons were learned.
Clonability
Currently the fp-bindgen Runtime can be Cloned. However, the new Wasmer 3 Store cannot be cloned. This is arguably an improvement, but in order to make sure that our Runtime struct can still be cloned, we have to do some work. If we don't keep Stores around across method calls, but simply create new ones, that should already solve the issue, though. It seems that to create a new Module you need a Store, but this store is not actually used in the Module creation. Therefore, I guess a Module can be reused even across stores.
Mutability
In Wasmer 3 function invocations require a mutable wasmer Store. In Wasmer 2 this was not the case. Method calls on our generated Runtime struct would therefore also need to become mutable. Arguably this is more correct, since method calls are mutating memory and so on. However, it is a change to be aware of and would potentially be breaking to our users. If the Runtime remains cloneable, though, it may be less of a worry. Some extra details here: wasmerio/wasmer#3530
Feature
For compatibility purposes (and the changes listed above) it would be nice if users of fp-bindgen can choose whether to use the existing Wasmer 2 support or move to the new Wasmer 3 support. It would be nice if we can place the Wasmer 3 support behind a new host feature flag.
(note: ticket updated on March 6th after discussion with @kajacx on Discord)
The text was updated successfully, but these errors were encountered:
Intro
We want to support Wasmer 3 in fp-bindgen. However, Wasmer 3 brings with a few changes that make it less than trivial to upgrade to it. This caused our initial upgrade approach to fizzle out, but some lessons were learned.
Clonability
Currently the fp-bindgen
Runtime
can beClone
d. However, the new Wasmer 3Store
cannot be cloned. This is arguably an improvement, but in order to make sure that ourRuntime
struct can still be cloned, we have to do some work. If we don't keepStore
s around across method calls, but simply create new ones, that should already solve the issue, though. It seems that to create a newModule
you need aStore
, but this store is not actually used in theModule
creation. Therefore, I guess aModule
can be reused even across stores.Mutability
In Wasmer 3 function invocations require a mutable wasmer
Store
. In Wasmer 2 this was not the case. Method calls on our generatedRuntime
struct would therefore also need to become mutable. Arguably this is more correct, since method calls are mutating memory and so on. However, it is a change to be aware of and would potentially be breaking to our users. If theRuntime
remains cloneable, though, it may be less of a worry. Some extra details here: wasmerio/wasmer#3530Feature
For compatibility purposes (and the changes listed above) it would be nice if users of
fp-bindgen
can choose whether to use the existing Wasmer 2 support or move to the new Wasmer 3 support. It would be nice if we can place the Wasmer 3 support behind a new host feature flag.(note: ticket updated on March 6th after discussion with @kajacx on Discord)
The text was updated successfully, but these errors were encountered: