Re: Dumping and restoring side-effects

[Greg Troxel <gdt at fnord dot ir dot bbn dot com>]

I have no real experience here.  (The biggest thing I hooked guile
into is gated, and I didn't try unexec.)

Your freshen approach sounds reasonable.  It occurs to me that this
can be viewed from a somewhat greater distance: the smob has state,
and there is an invariant that this corresponds to some state
someplace else.  It's helpful to state these invariants explicitly,
and to be able to check them.  The code to check them and the freshen
code are almost the same; I'll offer the strawman that one could have
a function that checks the invariant if called with #f (and throws an
exception if not met), and fixes the invariant if called with #t
(returning #f if ok, #t if fixed).  If this were made a standard smob
slot, reexec (the stuff done after starting an unexec'd program :-)
could just call it for all smobs.

Also, I'm not sure it's good to have an unexec'd program open a
connection to the X server at all before unexecing.  If you seperate
making a color and actually causing X state (on first use, memoized),
you might be able to avoid this.  Plus, it seems suboptimal to require
X11 to undump; it should work as part of an automated build.
But this is an argument about one of the many possible problems you
could avoid otherwise, not against smob fresheners in general.

I'm not sure fresheners can work with all external objects given my
invariant checker/freshener idea; not all external APIs are
idempotent.  But it sounds like you are proposing a freshener to
recreate external state when it is known that the external state is
nonexistent; this is easier than an unknown/untrusted external state.

        Greg Troxel <gdt@ir.bbn.com>