[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: Michael Livshin
Subject: Re: heads up (was: Re: Making guardians a module?)
Date: 29 Dec 2000 19:40:23 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Dirk Herrmann <address@hidden> writes:

> On 28 Dec 2000, Michael Livshin wrote:
> > Dirk Herrmann <address@hidden> writes:
> > 
> > > But, why do you try to avoid marking self-cycles in
> > > scm_gc_mark_dependencies?
> > 
> > because self-cycles are perfectly acceptable, finalization-wise.
> Can one really be sure that a directly (but not indirectly)
> self-referencing object is safe to finalize?

yes, one thinks one can. ;)

the guardian's job is to say: here, this object is not referenced by
anything anymore.  it's the caller's job to handle any self-cycles
(or, in fact, any other semantic peculiarities) of the object.

> Whether or not a cyclic structure is safe to finalize depends on the
> semantics of the structure, not on the question whether the cycle is
> 'short' (i. e. from the object directly to itself) or longer.

exactly.  the thing is that guardians can't deal adequately with
"long" cycles, but "short" ones present them no difficulty.  no more,
no less.

> The nice thing about the greedy guardians is, that they still
> fulfill (almost, see below) the specs of the Dybvig guardians,
> because Dybvig's original definition of guardians makes no
> guarantees that an object will _ever_ be returned by a guardian.
> That's just because of the way garbage collection works.  Therefore,
> using greedy guardians does not change the semantics of any program
> that up to now has used guardians.

any program that we know of, that is. ;)

> The only difference (which I referred to above) is the impossibility to
> guard an object more than once with different guardians.

or with the same guardian.  there's no difference, and quite
intentionally so.

> However, this is something which has not been discussed in Dybvig's
> paper anyway, and the semantics are not clear either.  Thus, we
> don't lose much if we just disallow it.  (If we want to allow it, we
> could give it a nice semantics like: Independent of how many times
> an object has been registered with guardians, it will be retrieved
> at most once.  And, the object is protected from garbage collection
> as long as there is at least one of the guardians alive with which
> the object was registered.  While this seems to be a clean semantics
> (for me, at least) it requires a lot more bookkeeping to get right,
> thus it is questionable whether it is worth the effort.)

I'm not convinced that it improves anything (well, modulo the buggy
aspects you pointed out in your mail, which I hope to solve through
less drastic measures).

> Thus, I'd vote for just kicking those sharing guardians out, until
> there is a real use for them.  Otherwise we suddenly end up with the
> big 'backwards compatibility' problem if we once decide to drop them
> from the library :-(

they are not such a bear to support, actually.  I hate to kick things
out when there's any possibility of them being useful to somebody.
never having implemented them in the first place is another thing. ;)

> > thanks for feedback,
> Thanks for your work on the guardians!

can I get the big and shiny "spending effort only on unimportant
features" award, already? ;)

The whole idea of modules is so separatist, anyway.  Can't we all just
get along?                                               -- Jim Blandy

reply via email to

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