Re: Dumping and restoring side-effects

[Miroslav Silovic <silovic at zesoi dot fer dot hr>]

"Greg J. Badros" <gjb@cs.washington.edu> writes:

> My current (rough) plan is to have each SMOB have a freshen method (like
> the mark, print, free methods) and keep a (weak, for GC purposes) list
> of objects that need to be freshened after dumping.  I'd only track the
> list when the --dump option is given and only do the freshening when
> started from an unexec'd binary.  This would require two big changes to
> Scwm: 
> 
> 1) Writing the freshen methods for the various SMOBs that have
> side-effects that cannot be maintained by an image of the heap.
> 
> 2) Adding code to SMOB constructors to insert objects that'll need
> freshening into the weak list.

The alternative here is to use GOOPS - especially if it is going to
become part of Guile. In that case, you'd just specialise freshen
generic to a specific smob (which, if I understand GOOPS/C interface,
already has GOOPS class attached).

Note that the difference is not purely aesthetic: GOOPS would allow
you to write refresh functions in Guile, not just C.

> 3) Running the freshen routines (in-order) after a restart of an
> unexec'd binary.

in-order is the catch - one of my projects (not guile related) had a
big problem getting itself initialised in proper order after dumping
large data graph and reading it back. In your case, order of
allocation sounds fitting for all the purposes I can think of, but
there -could- be a way to break it.

-- 
How to eff the ineffable?