[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Interesting issue with managing GC of proxies across process boundaries.
- From: Daniel Silverstone <dsilvers@...>
- Date: Mon, 13 Aug 2012 16:18:30 +0100
On Mon, Aug 13, 2012 at 11:09:45AM -0300, Roberto Ierusalimschy wrote:
> If you really need to know that object is "about" to be collected (that
> is, it was removed from the weak table but did not run its finalizer
> yet),
It's less about knowing that it's about to be collected and more about the fact
that code running between the 'disappearing as a value' and having the __gc
called will be confused. Remember that this is multi-process and that the __gc
event is being propagated between processes running on independent timebases
:-)
> use an extra strong table that is a set of the tags not yet
> finalized. Tags are removed from this table by the corresponding
> finalizer. If a tag is in the weak table, it is well and alive.
> If a tag is not in the weak table but is in this extra table, its
> object is about to be finalized. If a tag is in neither table,
> its object is really dead.
That's essentially the approach I chose to implement (it's in soak testing
right now).
I maintain a strong table of tag -> nr-of-proxies-made and the __gc method for
the proxies now decrements that refcount and only propagates the __gc across
the link if it hits zero.
Assuming this soak-tests out as working nicely, I'll have to deploy it to my
Gitano instance and try it in real-world situations.
Thanks for your response, it has at least validated my final approach as 'not
completely insane' :-)
D.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69