> On Oct 14, 2023, at 5:14 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
>
>
> On Sat, Oct 14, 2023 at 3:05 PM Marc Feeley (via srfi-246 list) <xxxxxx@srfi.schemers.org> wrote:
>
> I’m not particularly fond of the proposed API.  Abstractly a guardian is an interface to the garbage collector.  At any point in time the guardian can be queried to determine if some object registered with the guardian has become “unreachable”
> That's not actually true.  If I have an object x, it is by definition not (strongly) unreachable.  So there is both no way and no need to interrogate a guardian to know if a particular object is reachable.

I don’t mean that you can query if a specific object x is no longer reachable but rather query the guardian to know if there is an object registered with the guardian that has become unreachable.

>
> (side note: I prefer the term “not strongly reachable” which distinguishes the kind of reachability we are talking about, because it is still “weakly reachable” through the guardian).
>
> Weakness in the sense of weak pointers is orthogonal to guardians, except that if an object is in a guardian, then there can never be a reason to break a weak pointer to it.  So I prefer to reserve "weakly reachable" to mean "reachable through a weak pointer".

That can’t be right. It is not an interesting property that an object is reachable through a weak pointer. When an object is reachable through a weak pointer it does not mean it is not also reachable through a strong pointer. What matters is if an object is not reachable from the roots by only traversing strong pointers.

>
> The main problems with guardians is that they:
>
> 1) Use a custom protocol for iterating over the currently not strongly reachable registered objects.  This protocol is yet another way to iterate over a sequence (there are already lists, generators, ports, etc).  It would be nice to use one of the existing protocols so that guardians can reuse familiar iteration patterns.
>
> I (following Chez) am careful not to assert that there is ordering inside a guardian.  The protocol simply returns some available unreachable object.  In practice the unreachable objects are typically kept in a queue a la SRFI 117, but that should not determine the API.
>
> If we decide to stick with generators, I would be happy to change the SRFI to return an eof object rather than #f, since there is no reason to put an eof object in a guardian any more than there is reason to put #f there.  That would mean it was using the lightweight generator protocol.
>
> 2) There’s a scalability issue because guardians are passive.  In order to implement a finalization mechanism there’s a need for some thread of execution to “poll” the guardian once in a while to process the newly not strongly reachable objects.  An alternative it to use a mechanism (not proposed by this SRFI but available with Chez Scheme) to be notified of a garbage collection in order to check the new state of the guardian(s) and proceed with the required finalizations.  Note that this still requires polling, but only when a GC notification is received.  This does not scale to large numbers of guardians.
>
> A better API would be to view a guardian as a stream of objects which represents the order in which the registered objects have been discovered to be not strongly reachable by the GC.
>
> I don't understand what semantics this sequence is supposed to have.

Because the guardian can only deliver one object at a time there is an ordering of the objects that come out of it, so it is a stream of objects. The order *could* be related to when the GC has discovered that these objects were no longer strongly reachable (i.e. basically a pipe between the GC and the guardian’s consumer). My point is not that it has to be that way but rather that a guardian represents a stream of objects.

Marc