Re: Userdata finalization order

[Ico Doornekamp <lua@...>]

* On 2010-10-17 Petri Häkkinen <petrih3@gmail.com> wrote  :

> On 15.10.2010, at 23.58, Wesley Smith <wesley.hoke@gmail.com> wrote:
>
>> On Fri, Oct 15, 2010 at 10:48 PM, Petri Häkkinen <petrih3@gmail.com> 
>> wrote:
>>> Hi,
>>>
>>> The reference manual says:
>>>
>>> 2.10.1
>>> "At the end of each garbage-collection cycle, the finalizers for  
>>> userdata are called in reverse order of their creation, among those  
>>> collected in that cycle."
>>>
>>> Does this mean that sometimes userdata may not be collected in  
>>> reverse order, i.e. when objects are collected in different cycles?
>>>
>>> If this is the case, writing Lua bindings for complex C++ libraries  
>>> just become more difficult in my mind. For example, there are  
>>> typically all sorts of managers, and dependencies between objects  
>>> that need to be teared down in proper order (reverse order of  
>>> creation).
>>>
>>> I'm asking this because I just hit a case that causes a crash in a C 
>>> ++ physics library when shutting down Lua. Basically there are a few 
>>> manager objects which get collected before some other objects that 
>>> have been created through the managers, and the physics library 
>>> doesn't like that at all.
>>>
>>> What would be the recommended practice to deal with these situations?
>>
>> You can't rely on userdata being collected in a particular order.
>> You'll have to implement some kind of notification system or improve
>> your collection logic when closing down a lua_State.  If a manager
>> gets deleted, it should notify any clients.  If a client gets freed,
>> it should detach itself from a manager.  If you implement this kind of
>> logic, there shouldn't be any crashes.
>
> Yep, that sounds sensible. It's just that tracking all those dependencies 
> is a lot of work (there are dozens of types/classes) and the binding is 
> already several thousand lines of C++ code so I was hoping for an easier 
> solution.

Facing a similar problem some time ago, we chose to go for light
userdata for object representation in Lua, avoiding garbage collection
altogether. This considerably simplified the Lua wrapper for the
library, and we take the extra work of keeping references and explicitly
destroying the objects for granted. Not a very Lua-ish solution, but it
seemed to be the right choice for our situation.

-- 
:wq
^X^Cy^K^X^C^C^C^C