Wasmtime GitHub notifications bot (Apr 06 2022 at 14:48): Wasmtime GitHub notifications bot (Apr 06 2022 at 14:48):devigned opened issue #4002:
Feature
When running a module with wasmtime, I would like to be able to capture the running memory of a workload, perhaps, while running, pause or stop the workload, move the workload elsewhere, then start the workload from where it left off.
Benefit
Being able to migrate a workload would enable workload state to be transferred to compute as the user of the workload is moving. Imagine someone driving down the highway and the workload traveling along edge compute with the user.
Implementation
Todo if the feature is interesting to the project.
Alternatives
One alternative is to externalize state from the module through some stateful service / component interface. However, this would require module developers to take a dependency on some service interface and rebuild applications to integrate with this external state store.
/cc @squillace
Wasmtime GitHub notifications bot (Apr 06 2022 at 15:24):bjorn3 commented on issue #4002:
If the callstack is empty you can take an approach similar to wizer which doesn't require wasm engine support. If it isn't due to optimizations I can only see it working for the exact same compiled version of the wasm to native code. Wasm code calling into user provided functions calling back into wasm code is effectively impossible to snapshot I think.
Wasmtime GitHub notifications bot (Apr 06 2022 at 18:47):devigned commented on issue #4002:
Thank you for the pointer and quick reply, @bjorn3. I'm going to a bit of homework and post back.
Wasmtime GitHub notifications bot (Apr 06 2022 at 18:47):devigned edited a comment on issue #4002:
Thank you for the pointer and quick reply, @bjorn3. I'm going to a bit of homework on wizer and post back.
Last updated: Oct 23 2024 at 20:03 UTC