guile-devel
[Top][All Lists]
Advanced

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

Re: Making guardians a module?


From: Michael Livshin
Subject: Re: Making guardians a module?
Date: 07 Dec 2000 14:44:56 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Marius Vollmer <address@hidden> writes:

> Dirk Herrmann <address@hidden> writes:
> 
> > On Wed, 6 Dec 2000, Dirk Herrmann wrote:
> > 
> > > 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.  Assume for example, that every port that is
> > > created is placed into a guardian, to allow for a close operation if the
> > > file object gets lost.  Further, assume that the user puts a pair
> > > consisting of a string and a port into a guardian, with the intention to
> > > print out the string to the port as soon as the pair gets lost.  Now
> > > assume that the pair actually gets lost and with it the port.  Then, the
> > > pair can be fetched from the pair's guardian, and the port object can be
> > > fetched from the guardian that stores all ports on creation.  
> > > Unfortunately, there is no protection agains the case that the port is
> > > fetched first by some code, that then performs finalization (i. e. closes
> > > the port) and only later the pair is fetched from the other guardian.  
> > > The attempt to print out the pair's string on the port will fail, because
> > > the port is already closed.
> > 
> > To see this effect, here is an example program:
> 
> I think we should fix this.  References from objects that are about to
> be returned from a guardian should not be considered dead, the
> referenced objects should be marked.

they *are* marked.  but they are not considered "live" because they
are not reachable other than through guardians.

(in retrospect, I really regret using the names "live" and "zombie"
for the object states that guardians deal with.  staying with Dybvig's
"reachable" and "unreachable" would have been less confusing, it
seems).

> In your example, the port would not be returned by the port-guardian
> as long as the cell is in the cell-guardian.
> 
> Is this possible?

yes, I think it is.

the smart way would be to order the "zombification" topologically, so
that you'll get the behaviour you ask for above.  I suppose it's
implementable, but I'll need to think about it some more to be sure
there are no semantic pitfalls.

[ glimpse glimpse ]

oooh, I found a very enlightening discussion in my GC list archive.
here is an excerpt (is that the right word?  I need coffee):

Hans Boehm writes:
<quote>
It effectively handles finalization in a single-threaded environment by
queueing objects need for finalization, and then running finalizers at the
programs explicit request.  (The same technique, minus the nice Scheme
embedding, was described in the 1985 PARC tech report by Paul Rovner.)

As far as I can tell, it pushes the dependency issues back into the hands of
the programmer.  As I've argued before, this doesn't strike me as a good idea.
 Ordering requires flobal dependency information, which the garbage collector
has, but the programmer doesn't.
</quote>

they discussed at length the merits (and demerits) of guardians
vs. topological finalization.  I can forward the whole thing to anyone 
sufficiently interested, as I have it handy here.

I think we can actually have both (i.e. a topological finalization
scheme (probably based on guardians), and bare guardians).  I'll post
a separate message with a design when it's sufficiently settled.

-- 
If all the economists in the world were laid end to end, it would probably
be a good thing.




reply via email to

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