neumond (Jul 28 2020 at 09:58): neumond (Jul 28 2020 at 09:58):Hello, I would like to be able to suspend wasm machine execution, scrape whole execution state, and persist it to be able to resume execution even after application restart. Users write their code as wasm binaries and launch them on a server. Wasm provides the sandbox, application provides specific API. But nuance here is that all the launched binaries can be very long playing and must be persistable to survive server restarts and to be independently paused/unloaded by server at any moment of time.
Persisting memory instances should be quite straighforward: they're simply chunks of continuous bytes. But I'm in doubt if it's possible to access/reconstuct the stack. And if it's possible to pause in any place, even in the middle of wasm code (and call/jmp it again to the same place).
Most likely all of that is not possible with current API. What amount of effort is required to implement this? (I'm not asking to do this, or even to merge such features into upstream, I just need to know how deep is the rabbit hole).
Alex Crichton (Jul 28 2020 at 17:54):@neumond indeed yeah the call stack is the hard part, and this is something that wasmtime doesn't currently support
Alex Crichton (Jul 28 2020 at 17:55):afaik the "best" way known to implement this is to run wasm on a different call stack so you can serialize that out as well
Josh Triplett (Aug 08 2020 at 16:33):@neumond Lucet has similar requirements. You might talk to @Aaron Turon.
Last updated: Dec 23 2024 at 13:07 UTC