Re: 1.6.0 and guardians

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

> On 6 Sep 2001, Michael Livshin wrote:
> 
> > 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.
> 
> Hmmm... I still don't get it:  What is the resource you want to re-use by
> destroying the guardian?

the ability to greedily guard the objects in it.

> With ports, closing one port allows you to open another one.  With
> guardians, you can open as many as you like.
> 
> The scarce resource is actually the possibility to register a single
> object.

if you are talking about that object, yes.  but I don't.

`destroy-guardian!' is a result of solving semantic constraints.  it
is not there because it's terribly useful, but because it un-breaks
the semantics.

the constraints (facts are stubborn and ofter not very beautiful
things) are as follows:

* guardians are regular Scheme objects.

* Scheme objects can become unreferenced.

* guardians hold scarce resources.

* GC finalization is neither timely nor guaranteed.

quite similar to file ports, isn't it?

> However:  Again I want to make it clear that I don't consider
> `destroy-guardian!╢, nor `unguard╢ nor `guarded?╢ as useful
> concepts.

neither do I.  but if you ever want to make a non-permanent greedy
guardian (whether it's useful or not is irrelevant as long as it's
_possible_), then you need a way to ensure, prior to getting rid of
it, that the scarce system resource it holds gets freed.

-- 
All ITS machines now have hardware for a new machine instruction --
COM
Clear Operator's Mind.
Please update your programs.