Re: [PATCH] thread-safe handling of asynchronous events

[felix . winkelmann]

> Perhaps simply we can just return two values?  The first a polling
> procedure and the second a procedure to add new objects to the
> finalizer?  You can just receive the polling procedure in a
> single-value context and ignore the object-adder if you don't want
> to use it.

That was also my thought. The problem here is that having a single
finalizer proc makes it possible to finalize on that procedure as well.
Splitting it into consumer/adder now has two procs holding on to
the queue and both must be released.

>
> Alternatively, make-finalizer could return a new structure type that
> represents the finalizer.  It could just be a wrapper for the queue
> internally.  We'd have to add a getter and an adder procedure that
> accepts this new object type (and perhaps a predicate).

Also an idea. Currently I prefer the following approach. I somehow
like the elegance of having a single procedure instead of creating
yet another data type and the usual bunch of operators.

(make-finalizer OBJ ...)
    as before, but returns a "decorated" proc.

(add-to-finalizer FPROC OBJ ...)
    extract the decoration and add finalizers to the objects finalizable
    via the already existing FPROC.

> > > Separating the collectable object from the context prevents the
> > > collected object from re-entering the live system through the
> > > finalization procedure (it may set! some variable to it, for example
> > > and that's not desirable).  Apparently, this makes ephemerons easier to
> > > implement.
> > > I found this through Taylor Campbell's comment on Andy Wingo's blog post:
> > > https://wingolog.org/archives/2022/10/31/ephemerons-and-finalizers
> >
> > I don't quite understand why many APIs are so afraid of retaining
> > the finalized object. The point is becoming aware of the object
> > being reclaimable. If it survives yet another GC cycle, so what?
>
> This would be problematic if the finalizer has run and deleted the
> foreign object, while there are still weak references that hold onto
> the object.  This has then become invalid/inconsistent.

I don't understand this, I'm afraid. Finalizers can always "revive"
objects, this can't be avoided and may sometimes even be required.
If weak refs suddenly make our memory model unsound, then the whole idea
of weak references stands to discussion.

>
> And vice versa, if there are weak references which are now broken, and
> the finalizer restores the object, this might cause different kinds of
> inconsistencies to arise.

The user is already fiddling with the consistency of the pointer
universe when using weak refs. I see no way to address this here without
removing weak refs or finalization.


felix