4 ms·
As it was mentioned, this sounds very much like time-traveling debuggers like RR, which also records such database. But I don't exactly understand: If you exac
by albertzeyer 3y ago
As it was mentioned, this sounds very much like time-traveling debuggers like RR, which also records such database.
But I don't exactly understand: If you exactly recover the same state, don't you end up with the same faulty undesirable state? (That's what you also get with RR, by intention, to debug the problem.)
Clearly, here this is not the intention, i.e. you don't want to recover exactly the same state. So, it means, some parts will not be recovered. How would it be decided what parts to recover and what parts not? This seems like an impossible problem to solve in general.
And then, the state will not be exactly the same. It might be now in a sane state, but is it the right state that the user wants?
- mark_undoio 3y agoI guess it insulates you against bugs in the VM implementation, plus against (transient) failures of the host system.
- albertzeyer 3y agoAh, right, that would be an option to define a clear boundary, i.e. to recover exactly the VM state, but not the OS native state. I was thinking about a native app here, where there is no VM. But this would cover only some specific set up failures, namely where something goes wrong in the host, which you can easily recover by resetting its state and retrying again. This is only a very limited amount of failures. I guess most failures come from bugs in the user code, which would all be state within the VM. Also, maybe your app depends on some resources from network, e.g. some NFS, or maybe some other remote server, or whatever, which you anyway cannot control. This is not easily recoverable then. (Tools like https://criu.org/Main_Page https://criu.org/Main_Page, which try to serialize an app state, to be able to recover it later, have the same problem.)