[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]
Board
Settings Home
/g/ - Technology



Thread archived.
You cannot reply anymore.



File: 39.jpg (63 KB, 493x467)
63 KB
63 KB JPG
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.
>>
>>64127947
You mean in Android?
>>
>>64127972
No desktop GNU/Linux I mean. Mint
>>
File: brainlet-20348.png (4 KB, 205x246)
4 KB
4 KB PNG
>>64127972
Not OP but obviously not, tf is wrong with you?
>>
>>64127947
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.
>>
>>64128260
Ah yeah I see. Thanks for the readups
>>
This is possible with containers.
https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781785888946/3/ch03lvl1sec20/freezing-a-running-container
>>
>>64128260
bullshit
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.
>>
>>64127947
>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.