1. RE: Checkpoint
- Posted by Henri.Goffin at sbs.be
Nov 02, 2001
Ricardo,
IMHO this facility is typically the operating system's job, not a prog. language
one. But I would also say that Rob would be ill advised to try to implement
anything of that kind in Euphoria, lest he's ready to open and moderate a
separate forum dedicated solely to the subject.
I spent almost 10 years of my career as a mainframe OS programmer and we had
such a facility built into the OS. It consisted (and, AFAIK still consists) of a
CHECKPOINT system call and a RESTART command. It worked pretty well. BUT despite
a lot of caveats and thoroughly documented limitations we still had to cope with
a lot of bug reports, at least half of them being user errors (read: naivete).
Indeed it is hard to provide for evreything that can change in the runtime
environment of a program between two sessions (i.e. shutdown or crash and
reboot). Even between two runs of the same program in the same session you cannot
avoid changes. For instance dynamically acquired memory blocks will be at
different addresses so that simply dumping memory to a file at checkpoint time
will be inoperant at restart. Right now I just remember the most obvious traps,
but believe me, any OS can play much more vicious tricks that prevent such a
facility to be 100% reliable. Unless you make it very, very sophisticated... and
thus heavy and expensive.
After all this is no suprise if dear Bill never said a word about "offering"
such a useful feature in his ultra-functional, hyper-reliable OS's. The guy is to
wise not to be aware ;)
Henri Goffin (from Belgium)
> -----Original Message-----
> From: rforno at tutopia.com [SMTP:rforno at tutopia.com]
> Sent: Friday, November 02, 2001 2:58 PM
> To: EUforum
> Subject: Re: Checkpoint
>
>
> No. I was thinking only about variables and the point of execution, but now
> that you mention it, open-file-status would be useful, although I don't see
> how to implement it. The data that has been written is still there, so that
> it should be backupped by the user if he wants so. Probably you noticed that
> I am missing this facility from APL...
> ----- Original Message -----
> From: "Robert Craig" <rds at RapidEuphoria.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Thursday, November 01, 2001 8:10 PM
> Subject: Re: Checkpoint
>
>
> > rforno writes:
> > > I think that it would be very useful the ability to write a checkpoint
> or
> > > snapshot to disk at a certain point in the program, so that if, for
> example,
> > > the power fails, it can be reinitiated at the point of failure
> >
> > Well, maybe I'll add some sort of commit and rollback
> > facility to EDS, but I can't see trying to do a general one
> > for all programs.
> > Do you expect Euphoria to remember the entire state
> > of the program, including all open files, and what has been
> > read/written so far, as well as what has been written to the screen,
> > what API calls have been made, etc?
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
> >
> >
>
2. RE: Checkpoint
If all the variables for the program are processed through a single
sequence then that sequence can be saved to file at any time.
Another possibility is for only the variables that you feel are crucial
for saving to be stored in a single sequence for easy saving.
A better method uses a C like capability. Being able to store a pointer
to the variables that you want to save in a sequence.
Then you could go through that sequence saving the value of each
variable that you have a pointer to.
Also you could make global the variables that you want to save.
Then put them in a save_var() type of routine that writes those
variables to file when desired.
None of the above solutions take into account the current point of
execution. That would have to be stored in a variables to be written to
file.
Also, the program would have to be designed to be able to skip to the
point at which it was last saved.
Good luck on that last part. Recursive calls can be very difficult to
jump back into.
Lucius L. Hilley III
