lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

 On 17/10/2010 07:17, Petri Häkkinen wrote:
On 15.10.2010, at 23.58, Wesley Smith <> wrote:

On Fri, Oct 15, 2010 at 10:48 PM, Petri Häkkinen <> wrote:

The reference manual says:

"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.
In a much simpler project I had images and sub-images exposed to Lua scripts. Sub-images were just a pointer to an image and information about the viewport of the sub-image into the image. Of course the collection of images when sub-images were still alive would cause a crash.

I solved this by adding the pair sub-image=image to the registry whenever a sub-image was created, and setting sub-image=nil whenever a sub-image was collected. This ensured the correct collection order for these data as an image would only be collected after all sub-images were collected.