This is the mail archive of the
mailing list for the Guile project.
Re: Dumping and restoring side-effects
- To: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Subject: Re: Dumping and restoring side-effects
- From: Miroslav Silovic <silovic at zesoi dot fer dot hr>
- Date: 03 Feb 2000 16:08:52 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <firstname.lastname@example.org>
"Greg J. Badros" <email@example.com> 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
> 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?