[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Home]
Settings Home
/g/ - Technology

Thread archived.
You cannot reply anymore.

File: 39.jpg (63 KB, 493x467)
63 KB
Is it possible, on linux, to save a program's memory in a file and load it again? Like for example in emulators where you can save the state of a game at any time you want.
You mean in Android?
No desktop GNU/Linux I mean. Mint
File: brainlet-20348.png (4 KB, 205x246)
4 KB
Not OP but obviously not, tf is wrong with you?
This is difficult to do because of the way programs interact with each others and all of the shared state in the kernel, etc. When you "rewind" a process, everything that it is connected to might not react well to that.
A lot of virtualization softwares support doing it for whole VMs though.
And there are some projects that try to implement it for ordinary processes (like CRIU) but I don't know how well this works.
I remember DragonflyBSD has it built-in, but also no idea how well this works.
Ah yeah I see. Thanks for the readups
This is possible with containers.
it's difficult because it wasn't a feature request for quite a while, hence kernel/process handling has evolved without considerations for such a feature
even so, it ain't as shit as it could be
basically, your process' environment is:
- 1. virtual memory
a) non-modified pages can be dropped, as long as there is a source for them to be restored from (mmapped binaries, data files, etc.). Keep checksums, obviously, and fail fast if those don't match.
b) modified pages - this is the real deal. Dump em to some storage and yer done. Need to touch virtual mem and VFS susystems, but we've already got a decent part of the code used to implement hibernation

2. I/O:
- simplest first: stdin/out/err: throw enough data into storage (source, offset, checksums, etc) to be able to restore it
- open files: most user shit might not change, some other might (/sys, /proc, etc.) - bit more thought needs to be put here. Quickest MVP: throw "files changed underneath me" handling responsibility to the program if it wants to be "nv-pause-compatible"

3. Interaction with other processes:
- get bent. Got pipes/sockets to others? Yeah, tough shit, same story as above. Quickest MVP: throw "shit changed underneath me" handling responsibility to the program if it wants to be "nv-pause-compatible"

Reality check tho: is it a common enough use case for enough resources to be invested? Didn't think so. Say hello to workflow inertia for me.
>serialize all data during program lifetime
>save it to file
>open program
>load in serialized data from old run
best way to do this, minimizes time spent memcpying to
boost serialization is worth looking at

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.