[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heads up (was: Re: Making guardians a module?)

From: Dirk Herrmann
Subject: Re: heads up (was: Re: Making guardians a module?)
Date: Thu, 28 Dec 2000 16:55:57 +0100 (MET)

On 24 Dec 2000, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> > Some thoughts about guardians:
> > 
> > With respect to guardians one should know, that guardians are not a very
> > well thought out thing at all (IMO).  The interface is nice, but the
> > semantics are quite strange.
> I've just commited some changes that should give guardians more
> intuitive semantics without (almost) breaking the interface.  Please
> check it out and comment.  I'm especially concerned about naming and
> clarity (or lack thereof) of the NEWS blurb.

I have a question about your use of RECURSE:  Why are you defining it that
way?  For the standard scm_gc_mark, you just call scm_gc_mark.  But, why
do you try to avoid marking self-cycles in scm_gc_mark_dependencies?  
First, it just does not work, because as soon as there are indirections
across more than one intermediate object, the root object will get marked
anyway.  Second, it is basically the idea of the algorithm to get the root
object marked if it references itself, directly or indirectly.  Or am I
missing something?

Further, I don't quite get the difference between greedy and sharing
guardians.  What exactly does it mean for each type to guard an object?
In which case should which type of guardian be used?  Why do we need two
different types of guardians at all?

Another point:  The 'trick' from eval.c to include the code itself for a
second compilation pass is, well, not a beautiful thing :-)  It may still
be the best way to do things in this case.  But, if we are doing things
this way, shouldn't we split the code into gc.c and gc.template (or
whatever name) and use it as follows:

  /* Set up definitions for the creation of scm_gc_mark */
  #define <some definitions for variant #1>
  #include "gc.template"

  /* Set up definitions for the creation of scm_gc_mark_dependencies */
  #define <some definitions for variant #2>
  #include "gc.template"

This would allow to 'localize' the clutter, and to define something like
an 'interface' for the inclusion of "gc.template".  It would further allow
to have the corresponding function included in different parts of guile:  
the scm_gc_mark_dependencies function for example would fit better into

Best regards,
Dirk Herrmann

reply via email to

[Prev in Thread] Current Thread [Next in Thread]