Re: Confused by Lua garbage collection tear down order when there are references between objects

[Tim Hill <drtimhill@...>]

> On May 20, 2014, at 6:49 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> Am 21.05.2014 03:01 schröbte Tim Hill:
>> 
>> On May 20, 2014, at 5:15 PM, Eric Wing <ewmailing@gmail.com> wrote:
>> 
>>> I am trying to create a simple strong reference (Object A holds a
>>> reference to Object B) such that:
>>> 1) Object A keeps Object B alive (if all other references are disposed)
>>> 2) B outlives A
>>> 
>>> I'm seeing #1, but #2 is not working.
>>> 
>>> I am using userdata and using set/getuservalue in Lua 5.2/5.3w2 and
>>> basically putting objectB in objectA's user value table. (My specific
>>> implementation has Object A keep an array of objects it keeps strong
>>> references to.)
>> 
>> You cannot make assumptions about the order of GCing of unreferenced
>> objects. Once object A is unreachable, then if the only references to
>> B are via A (and hence B is also unreachable), both are GC candidates
>> and can be collected in any order.
> 
> They are collected in the reverse order that they were marked for finalization[1] (usually by setting the metatable), so B will always be collected before A if both become garbage at the same time, because it was created/marked last.
> 
> The only real solution is to change the order in which they are created, but you can try to decouple the finalization of the two objects via `luaL_ref`: You `luaL_unref` the B object in A's `__gc` method. The registry has a strong reference to B until A's finalizer has run, so B's finalizer will run in the next cycle. *But* this won't work at `lua_close` when the registry becomes garbage as well, all strong references are gone, and the usual finalization order applies ...
> 
>> 
>> If you really need cleanup to occur in a defined order you will need
>> to either release the reference to B first or make the __gc()
>> metamethods co-ordinate the ordering of cleanup.
>> 
>> —Tim
> 
> Philipp
> 
> 
>  [1]: http://www.lua.org/manual/5.2/manual.html#2.5

Frim a robustness standpoint its vad to rely on the order of GC .. If you want robust code you should not rely on specific GC behavior