Kevin Wiesmüller (Sep 20 2024 at 18:30): Kevin Wiesmüller (Sep 20 2024 at 18:30):Hey there,
I'm experimenting with wasmtime to dynamically call modules based on an event stream in Rust.
My events come in async and get handled in parallel wherever possible.
Until just now I had a single store per module and just tried to wire that up but am running into the Store not being threadsafe.
What's the best practice here? Is it intended that I make a store per invocation of my event handler (inside my WIT component) or is there a way for me to share things. What's the most efficient way of dealing with module instances?
Alex Crichton (Sep 20 2024 at 18:33):Efficiency here is sort of second to the desired runtime semantics of what you want. For example do you want two events over time to be able to go to the same instance? If so you're required to use the same Store for that, but if not then the two events won't be able to have state persisted between them (since the two wasm instances won't share state). Depending on your use case one might be more appropriate than another.
If you go the instance-per-event route though that's well supported in the sense that a Store<T> should be cheap to create and through InstancePre<T> you can quickly create a module instance
Kevin Wiesmüller (Sep 20 2024 at 18:50):I see. Let me give the instance-per-event a try as indeed any call to my modules should be hermetic.
Alex Crichton (Sep 20 2024 at 18:53):You do still have the option of persisting state in that scenario but it'll have to be done on the host instead of the module itself. Something like a key/value store that each instance gets access to or something like that (figured I'd mention)
Last updated: Dec 23 2024 at 14:03 UTC