If this is just a "wouldn't it be nice if" question, please let me know. I wondering if it's possible for a program to suspend itself - and just itself - to disk. Not suspend the system, but do something along the lines of writing all the addressable memory space of a program (probably C) to a file, with a note as to the location of the execution pointer, then later load the whole thing right back into memory, place the execution pointer and go.

I imagine that this would involve, at minimum, a little inline assembly, especially to arbitrarily move the execution pointer. So I guess there's three possible responses to this question:

1. Sure, you could do it.
2. You could do it, but it wouldn't do what you intend.
3. Not worth the effort / impossible.

Just kinda curious.

Oh, and I was only thinking of a single-thread single-process application, I know multi threaded would be a nightmare.

Sure, you could do it. It would be a very interesting project. Most of the stuff you want to do is already done in gdb, so get familiar with (1) using gdb and (2) the source of gdb, so you know how it does what it does.

An additional complication is that upon resumption you also want to reopen whatever files were open, and position your process to wherever they were in those files, yes? What about graceful error handling, in case those files disappear out from under you between suspension and resumption? How much sanity checking do you want to do to make sure the files haven't changed before resumption?

Whether you think this is worth all the effort is up to you. Is this "just" for fun (a perfectly serious reason, as far as I'm concerned), or is this "serious"? Is there a deadline?

Well, it's neither urgent nor just for fun. I would describe it as ... mostly just for fun. I thought it up when I noticed that Sylpheed-Claws can actually take some time to load up with all my plugins, and I was wondering if there was a way to avoid having to run a whole bunch of init functions over again. I think it would be really useful to be able to stash your gui away in file, as that often takes the chunk of init time. Hopefully, I'd love to create a C library that could provide this service to other programs - eventually. But, mostly a pipedream.

This is really an interesting task!

Are you trying to acheive something like,
taking a snapshot of the binary image during a particular point of execution in the memory and to resume from the same point where it was suspended ?

Well, I have few doubts with this and these are the tasks that comes to my mind ahead.

What is the addressable memory location that would be captured to the disk ?
It is the virtual memory address base and its segment memory address that would be available which thereby when the binary has to resume from the last instruction pointer may / maynot find the same address information ( mapping virtual address to physical address maynot be possible ) as it is, as the virtual address need not be the same all the time.


How to make sure that the pre-loaded modules are again available during resuming the operation from the suspended point of execution ?

PatrickNew, I don't use Sylpheed-Claws, whatever that is, but now you've gotten me interested in doing something like this. Darn you. Darn you to heck! (grin)

I'm not sure that the questions that kshkid raises should slow you down much. If you store everything that's in the process's address space, you can just reload that. That will take care of "pre-loaded modules". If you want to know how much to save from where, and the process is, say, process 2345, a quick and dirty way of finding each segment's virtual location and size is to do this:

What might be of more concern is: what files are open? What locks have been placed where in those files? Any semaphores and stuff?

well, sylpheed's loading is just what gave me the idea, I wasn't actually thinking of hacking it into sylpheed. I was thinking more along the lines of programs I may write from scratch. Perhaps one could require the program to track its own open files via presuspend() and postsuspend() type functions. Perhaps my biggest concern would be that I'd love it if this worked with gui apps, and that means shutting down and reinitializing a connection with the X server. That is, the same exact socket you used last time may no longer be available.

Well I dont mean to do that!

I was quite impressed by the task and idea that you guyz are discussing.

Regarding the locks and the file offset
Am not sure whether this would work or not, wont that be possible to read and dump the file table entries and get them back where the offset and the locks maintained by the process on the individual files are available !

Well, at least for the moment, I'm not expecting any of this to work without the application being aware of it. I'm sure you'd have to hand-write code for file IO. Mostly, I guess what I'm thinking of is sorta-done already. I've seen some c++ classes that use an XML file to give your objects persistence, I guess I'd just like that to expand to non object-oriented environments too.