Hi,
I planning to do it this way : Write a signal handler for the timer
signal recvd by a process, and every fixed period of time write the
process state ( the text portion, data portion, stack segment and
processor state, open file descriptors )to a file and  at a system
crash, read in the file and restore the state.
So this would require any program to be compiled with the process-
-state-save-and-restore-library .Any pointers in this direction would
be highly appreciated.
Thanks,
Prakash

[ Post a follow-up to this message ]

"Prakash Prabhu" <prakash.prabhu@gmail.com> wrote in message
news:85a4cc05.0409090952.4c41ec70@posting.google.com...
> Hi,
> I planning to do it this way : Write a signal handler for the timer
> signal recvd by a process, and every fixed period of time write the
> process state ( the text portion, data portion, stack segment and
> processor state, open file descriptors )to a file and  at a system
> crash, read in the file and restore the state.
> So this would require any program to be compiled with the process-
> -state-save-and-restore-library .Any pointers in this direction would
> be highly appreciated.

Prakash,

Do you plan to do it at system-level or application-level. If at system
level take a look at http://ftg.lbl.gov/checkpoint. Its a Open Source check
pointing effort available for most kernels. If at application level, take a
look at condor checkpointing library.

HTH,
Pirabhu

[ Post a follow-up to this message ]

>I planning to do it this way : Write a signal handler for the timer
>signal recvd by a process, and every fixed period of time write the
>process state ( the text portion, data portion, stack segment and
>processor state, open file descriptors )to a file and  at a system
>crash, read in the file and restore the state.
>So this would require any program to be compiled with the process-
>-state-save-and-restore-library .Any pointers in this direction would
>be highly appreciated.
>Thanks,
>Prakash

There is some known non-state-of-the-art (translation: it didn't
work very well) in saving and restoring process state in games such
as 'rogue' and 'hack'.  The problems come when you start saving
stuff and you don't know what you're saving (such as internal data
from C library open files, the termcap library, etc.).  The result
was a game which could save state, but you could only restore a
limited number of times (it ran out of FILE entries, since it didn't
know it could re-use them on restart), an ever-growing stack frame,
and an ever-growing data space on each restore.  Also, all heck
broke loose if you ever tried to run it on a terminal different
from what you started on, because the termcap routines knew that
they had determined the terminal type, and never checked it again.

Summary:  it works a lot better if you know what you're saving/restoring
and don't save and restore stuff you don't know about.

Gordon L. Burditt

[ Post a follow-up to this message ]