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

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

> 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.

yes.

> But, why do you try to avoid marking self-cycles in
> scm_gc_mark_dependencies?

because self-cycles are perfectly acceptable, finalization-wise.

> 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?

I'm not sure I understand the problem...  sorry if the following is
obvious:

the idea of the algorithm is to mark all the dependencies (perhaps
your "descendents" is actually a better term.  or maybe "successors")
of an object without marking the object itself.  this makes sure that
it is safe to finalize the object.  if the object references itself
_but_ there's no other cycles, then it is safe to finalize it.

> 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?

greedy guardians can only guard an object once.  you get an error if
you try to greedily guard an already greedily guarded object again.

sharing guardians behave more like those described in the Dybvig's
paper.  they are (theoretically, at least) useful for implementing
various kinds of weak dictionaries.  in general, they are useful if
you just want to be notified that some object died and don't want to
do anything destructive to that object (or resurrect it).

note that the greedy variety is the default, and the sharing variety
is there in case someone figures out what they are *really* useful
for. ;)

greedy guardians seem to be what people expect.  you can safely do
absolutely anything with an object returned by a greedy guardian:
modify, resurrect etc.

> 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 guardians.c.

I actually agree with you.  in this case, I just went with the status
quo, out of fear that breaking it may lead to a voluminous
discussion. ;) but since you already started a discussion -- yes, I
agree.  it would be nice to break up eval.c in this way too, it'd get 
a little more readable.

thanks for feedback,
--mike

-- 
Perhaps it IS a good day to die; I say we ship it!
                                        -- Klingon Programmer