Re: Interesting issue with managing GC of proxies across process boundaries.

[Roberto Ierusalimschy <roberto@...>]

> Now the problem...
> 
> I am encountering an interesting issue where the following sequence of events
> occurs:
> 
> Side 1 makes a call which returns a *new* proxied table (t)
> Side 1 then does not store that anywhere strongly.
> 
> Side 1 makes a call which returns the same table (t)
> Side 1 attempts to look up the proxy for t in the weak tables and does not
>        find it, resulting in an error
> 
> Where it gets interesting is that between the two calls, if the userdata proxy
> were being 'forgotten' I'd expect to see the __gc for it.  However, due to the
> two-stage nature of the GC'ing of userdata, the userdata disappears from the
> weak tables but has not yet had its __gc called.
> 
> Thus the error.

Objects as values in weak tables are cleared before running their
finalizers.  (Objects as keys in weak tables are cleared after running
their finalizers.)

Why can't you use the weak table itself to check whether the object
is being collected? If the object is not in the weak table, assume
it had been collected.

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), 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.

-- Roberto