This is the mail archive of the mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dumping and restoring side-effects

Miroslav Silovic <> writes:

> "Greg J. Badros" <> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]