This is the mail archive of the guile@sourceware.cygnus.com 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


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

> The issue is how to restore the non-process state of a dumped
> executable.  E.g., in Scwm, if I try dumping after evaluating this sexp:
> 
> (define red (make-color "red"))
> 
> Things are not going to work in the restarted executable because the
> `make-color' primitive alters state in the X server (via XAllocColor).

Yep, this is a real problem.

> After starting an unexec'd binary, various objects will need to have
> extra code executed to restore this state --- I'm thinking of this as
> "freshening" of the object.  It applies to numerous SMOBs, especially
> due to interactions with the X server.
> 
> 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.

Interesting approach.  When faced with issues such as this, I tried to
reorganize the initialization sequence into those parts that were
dumpable, and those that were not, and then perform the dump after the
dumbable part, and before the undumpable part.  Not very helpful, huh?

> Also, thoughts on how best to extend the SMOB table with the new
> function pointer to the freshen method?

typedef struct scm_smob_descriptor
{
  char *name;
  scm_sizet size;
  SCM (*mark) SCM_P ((SCM));
  scm_sizet (*free) SCM_P ((SCM));
  int (*print) SCM_P ((SCM exp, SCM port, scm_print_state *pstate));
  SCM (*equalp) SCM_P ((SCM, SCM));
} scm_smob_descriptor;

struct smob_with_mustard
{
  scm_smob_descriptor smob;
  int mustard_type;
}

I'm not sure it's guaranteed in the standard, but some tricky code
will create and use smob_with_mustard's, passing them to functions
that expect scm_smob_descriptor's, and things work OK.  I think.

-russ

--
Practice random senselessness and act kind of beautiful.

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