On Thu, Jul 27, 2023 at 12:30:46PM +0200, Peter Bex wrote:
> 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
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
Hi,
I think this clears things sufficiently up.
Please excuse me if I am missing some details...
Strong references are already ensured to be gone
and weak references are cleared using the incantations that sjamaan
(in his wisdom) proposed
What is the definition of a weak reference in
On Mon, Jul 10, 2023 at 09:28:19PM +0200, felix.winkelm...@bevuta.com wrote:
> After thinking some more about this, I realize that your approach
> (clearing weak ref's to finalized data) is the right thing, since
> any other behaviour in the presence of multithreading leads to
> disaster.
Thank
After thinking some more about this, I realize that your approach
(clearing weak ref's to finalized data) is the right thing, since
any other behaviour in the presence of multithreading leads to
disaster.
Let me elaborate.
Finalization is a time of reckoning, a purgatory where an object
> However, there's one more concern:
>
> > The potential use-after-free scenario can still happen if the object is
> > kept alive, regardless of how we handle weak refs, this is unavoidable
> > if we allow finalizers and keep the possibility of resurrection.
>
> I have thought about this a bit
On Fri, Jul 07, 2023 at 11:23:17PM +0200, felix.winkelm...@bevuta.com wrote:
> I'm not very comfortable with this change. This feels like trading in
> one inconsistency (weak refs being cleared for a potentially non-dead
> object) for another (potentially inconsistent ties of GC-controlled
>
