Wasmtime now includes features to attach state to a store, which is useful, however host APIs which depend on this are inherently unvirtualizable.
I wonder if anyone has ideas about how best to communicate that this feature is available and useful, but it's important to be aware of the implications
Could you expand upon how using state from a store vs. from a closure capture (i.e. with Func
) impacts virtualization so that I can understand the implications? The biggest problem I see is that state in a store is shared between all instances of that store, but users can still link in a Func
-based host function implementation at instantiation time when needed. At the bare minimum, we should be properly conveying to users that these Store
functions mean every instance in the store has access to the state assuming they also share the same host function import.
That's a good point, that closure state is effectively in the same category.
That is also to say the problem of shared state isn't new with config-defined host functions; I can define a Func
with state and import that same function into multiple instances.
yeah
config-defined host functions definitely made it easier to implicitly share that state though
so something that needs to be documented properly
Yeah. I'm starting to think about where and how we should document that
The doc comments for the Store
functions are woefully inadequate in conveying this :( that's my fault
No worries :-). We're all figuring this stuff out as we go here
I'm happy to do a follow-up PR to document this properly; besides calling out that the state in the store may be accessible to all the instances in the store (I can go into lots of detail so there aren't surprises), are there other concerns relating to virtualization I should convey?
One question that I don't know the answer to yet is, "who needs to worry about virtualization?"
Otherwise, I think that's it.
Last updated: Nov 22 2024 at 17:03 UTC