lua-users home
lua-l archive

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


Carsten thanks that thread has lots of good info.

For one thing, it specifically tells me that __gc can resurrect an object, but also that it may not work on LuaJIT, which is good to know, because I am using LuaJIT now. That's OK for me, I don't need to resurrect in __gc, I just need to ensure that __gc doesn't happen if I reuse the full userdata from the weak table (even after all strong references are gone) which does seem to be the case.

Otherwise, yeah, I'm doing pretty much exactly what you say. I want to divorce the lifetimes of the C++ and Lua objects. I'm *effectively* using the solution you describe with smart pointers, except without actually using smart pointers. (Basically, my Lua full userdata, C++ class, and another C++ class all know how to collaborate ownership.) And I'm extending the class with auxillary data.

So I have the same problem you noted, how to keep alive ("anchor") the auxillary data even after references go. In my case though, I'm not going to try to keep the auxillary data associated with the full userdata and therefore keep the full userdata alive. Instead, I'm going to keep the auxillary data associated with the light userdata and let the full userdata go away if it wishes. If the object lives on in C++, its auxillary data will also live on. It can be recovered when a new full userdata is made for it. This effectively means even though full userdata may come and go, the lifetime of the *conceptual* Lua object can be anchored solely through C++ (i.e. it can be a different full userdata but that's OK). This is sort of like how strings keep identity while they exist, but maybe not after they "go away and come back". The only caveat, as I mentioned earlier in the thread, is I need a "native" finalizer for when the C++ object goes away, to clean up any auxillary data, so it won't be reused for a new C++ object at the same address. That's OK, I have that.



On Tue, Nov 12, 2013 at 2:23 PM, Carsten Fuchs <carsten.fuchs@cafu.de> wrote:
Hi Marc,

Am 2013-11-12 20:09, schrieb Marc Lepage:

Still, reading through that thread, it *seems* to me like I should be OK, but it's not
*obvious* to me that it's OK.

I'm not entirely sure if I understood your problem, because, as someone else in this thread already mentioned, weak table entries either are collected (and removed from the weak table) or they are not (and still there).

When you bind C++ objects to Lua, using smart pointers is a great help, as they remove concerns regarding the lifetime of the bound object that is possibly used from both C++ and Lua, and possibly done with in one but still used in the other.

As you mention the problem of having only a single Lua instance for a single C++ instance, maybe this thread has some additional info for you?
http://thread.gmane.org/gmane.comp.lang.lua.general/92550

Best regards,
Carsten



--
Dipl.-Inf. Carsten Fuchs

Carsten Fuchs Software
Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany
Internet: http://www.cafu.de | E-Mail: info@cafu.de

Cafu - the open-source game and graphics engine for multiplayer 3D action