[DGD] Persistance

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> When you eventually do reboot, how will it
> reconnect the rooms? Doing it by 
> file name makes this easy, but by object
> reference, well, for a start every 
> room object will have to be loaded, and then
> how is it going to figure out 
> what rooms connect to where, if not by file
> name?
 
  Here's a clarification that may help.  Under Unix,
there's something called a core dump.  Conceptually,
it's kind of like a DGD statedump.  The idea is that
the process's memory is all written out, along with
*all* its state, into a big file.  That file contains
the entire application in exactly the state it was in
when it core dumped.

  Usually, coredumps are used for debugging.  But
certain very clever applications use them for other
purposes.  For instance, emacs and some Perl
applications use them for compiling.  They go through
a very long startup sequence (several hours for
emacs), and then the dump core *without* crashing.

  When you run emacs, or run a precompiled Perl
binary, what happens is that core dump gets loaded
right back into memory, in the exact state where it
dumped core.  From the newly-loaded app's point of
view, it just dumped core and now it's time to run. 
Every time you run the app, you're restoring from its
just-after-build application state, without having to
wait for hours of startup while it compiles many
megabytes of code.

  DGD statedumps work a lot like coredumps.  All your
current running code is dumped.  All your objects are
dumped.  All your data is dumped.  All the stuff in
the swapfile is dumped.

  And when you put it back, it's as though it had
never been gone.  If you have a chunk of code which
contains a statedump, you won't know on the line after
that statedump if you just breezed through it, or if
you've just been restored, minutes or weeks or decades
later, from that statedump.  Maybe all your net
connections just went down (they do that when you
restore years later, alas).  Maybe your system clock
just advanced by a couple of weeks.  It's hard to
tell.  Because your function will continue just fine
ten years later, and may *not even realize* that you
just dumped state and restarted.

  I'm exaggerating slightly.  I think the statedump
happens just after the thread exits.  But when the
call_out that you scheduled ten years ago happens, it
won't know that it was scheduled ten years ago.  It'll
just know that it's time to run again :-)




=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd