Re: How should we deal with weak refs to finalizable objects? (was: Re: [PATCH] Bugfix and drop weak references to finalizable objects (was: Re: [PATCH] thread-safe handling of asynchronous events))

[Peter Bex]

On Wed, Jul 26, 2023 at 04:45:53PM +0100, Andy Bennett wrote:
> So how can we finalise a circular list of objects all of which have
> finalisers and still maintain atomicity?
> 
> The docs say the order is "undefined".
> It seems that the best way to finalise this structure is to explicitly break
> all the strong references between components of the list (as we do for
> external weak references) before any of the finalisers are called.

I thought about this one too - it would be nice if all the finalized objects
that refer to other finalized objects would have these links cleared.
However, there are two main obstacles to that:

1) There's no (efficient) way to know if an object is a finalizable one.
   We need this because we can't simply clear *all* the objects inside
   a finalizable object that aren't referenced elsewhere, because we do
   want to keep foreign pointers etc which are only referenced by the
   finalized object itself.  So we'd need an efficient way to know if
   an object pointed to by a finalizable object is itself finalizable.

2) We have no (canonical) way of breaking strong references.  For weak
   references, it is clear that we have some special indicator, the
   "broken weak pointer" placeholder that gets put there when an object
   reference is cleared.

> It may also improve the memory model if we define the object that the
> finaliser receives as a "copy" of the object that has ("already") been
> garbage collected.

I don't really think this will make much of a difference either way - as
it is currently, you couldn't distinguish the "original" object from a
copy.

Possibly a better way is what MIT Scheme (and, gasp, JavaScript) does:
register a finalizer on object with an extraction procedure that returns
the value to finalize.  That way, the object getting deleted is not the
object that is getting finalized.  For instance, when a port would be
finalized, the finalization procedure receives the underlying file
descriptor and not the entire port object.

Although after giving that some more thought, I'm not 100% sure this
would really solve the issue - you can still extract complex objects
from the to-be-finalized object (or have the "identity" procedure as
the "extractor", so it returns the object itself) and therefore have
an object with other things pointing into it, and that could still
be resurrected...

Cheers,
Peter

signature.asc
Description: PGP signature