Re: 1.6.0 and guardians

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

> On 5 Sep 2001, Michael Livshin wrote:
> 
> > well, I implemented the non-greedy variety because the greedy variety,
> > while being better optimized for common usage, has some pretty ugly
> > warts.
> 
> Which ones?

and then later:

> > > Destroying of guardians is also a functionality that I can't follow.

this one, mostly.

> > here's the rationale, from the NEWS entry:
> > 
> > [snip]
> > 
> > note the use of "are usually" and "hardly very important".  without
> > the presence of `destroy-guardian!', I would have to dictate a style,
> > and I'd rather not.
>
> Then I'd rather use an operation 'unguard' that unguards a single
> object.

that wouldn't do the trick.

the situation is actually very similar to the situation with file
ports.  an open file port holds a scarce system resource (a file
descriptor).  a live greedy guardian also holds a scarce system
resource -- the ability to guard the objects in it.

ports have the `close' function, in order to achieve explicit control
over the use of their scarce resource.  so do greedy guardians.

> > > Further, there are (IMO) some weak points about the current
> > > interface: Instead of having a throw_p parameter for the function
> > > scm_guard, a separate scm_guarded_p predicate seems cleaner to me.
> > 
> > I considered this, but it isn't really any cleaner.  it's also not
> > thread-safe -- the state of the world might change under you between
> > checking whether the seat is taken and actually sitting down.
> 
> Yes, but this is something that can be taken care of on the user level, by
> some user level mutex.
> 
> However, I don't even consider this as usefull.

so we seem to agree on this point, right?  the ability to find out
whether an object is guarded should just be removed.

> > > Finally, the fact that objects in cyclic dependencies are reported is
> > > quite nice, but simply unguarding them seems wrong to me.  I can see
> > > several possibilities to deal with such objects:  a) Return them from the
> > > guardian as other objects and let the user deal with them, b) return them
> > > wrapped in some special smob object to indicate their specialness to the
> > > user (disallowing, however, to register such a smob with a guardian) c)
> > > just keep them guarded forever d) have some special system wide list
> > > for these objects where such an object gets transferred to if it is
> > > detected - then the user can from time to time fetch out these objects and
> > > decide what to do about them, like breaking the cycles.
> > 
> > I like variant d).
> 
> That's my preference also.

cool.

now let's get to some consensus on the `destroy-guardian!' thing, and
we'll have something implementable.

-- 
Long computations which yield zero are probably all for naught.