This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Dumping and restoring side-effects
Miroslav Silovic <silovic@zesoi.fer.hr> writes:
> "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.
Right; there's lots of cool stuff I think could be done w/ Scwm when
GOOPS is built into the core. For now, though, I'm gonna need to stick
with solutions that I can get working w/ guile-1.3.4 since Scwm startup
time is the last reasonable excuse to not be using Scwm, IMO (but I'm
biased, of course).
> > 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.
I view it as kind-of recording the side-effects as they happen, and
playing them back by freshening after re-execing. I'll have to think
harder about how it might break, but I don't doubt that that's a
possibility. I'm willing to live with things being somewhat fragile as
long as I can find a large subset of .scm files that Scwm can have
preloaded in a dumped executable that reduces the startup time
substantially -- my aim is < 3 seconds on my PIII box, with the full
system.scwmrc.
Thanks,
Greg