Re: problem with weak table and finalized objects

[Francesco Abbate <francesco.bbt@...>]

2010/8/29 Mark Hamburg <mark@grubmah.com>:
> As you already discovered, weak keys leading to userdata objects do not get cleared on the first GC cycle in which the objects are discovered to be otherwise unreachable. This is done because the __gc metamethod might need to use the data accessible via the weak table. This was probably essential before userdata's could have environment tables. I don't know that it is still essential and I could see an argument for removing this behavior. (5.2?)

Hi Mark,

thank you very much, this is very helpful and completely clarify the
problem. Actually my __gc metamethods doesn't do anything fancy, it
just frees the C++ resources (memory actually) of the object.

> This generally only affects one if you iterate the weak table. Otherwise, presumably, the keys are undiscoverable and hence, it doesn't matter whether they are in the table or not.
>
> My work around for this was to maintain an extra isLive fully weak table that mapped userdata objects to themselves and to check isLive when iterating a weak table that may have userdata keys. This works because the value side of the isLive table will get cleared on the first GC pass and hence a userdata that is headed for finalization won't show up in isLive.

I would like to avoid to add such an extra table if possible. I have
already a set of weak tables to mirror the relationships between C++
objects and I would like to avoid such an additional table just to
know which object is alive and which one is not.

What I would like to do is to patch Lua to change this kind of
behaviour. For me this is not a problem because a keep a copy of Lua
as part of the repository. I would greatly appreciate if you or
someone else in the list can give me some hints about which function
of Lua should I touch to change this behaviour.

Thanks again of the help! :-)

Francesco