Re: Userdata Lifetime Management (was Prevent userdata from being marked for garbage collection?)

[Carsten Fuchs <carsten.fuchs@...>]

Hi Vinnie,

Am 2012-07-04 04:37, schrieb Vinnie Falco:
> In my update to LuaBridge, I added support for three styles of
> "Lifetime Management" which directly address the use-cases you
> described:
>
> - Lua lifetime: Managed completely by Lua
> - C++ lifetime: Managed completely by C++
> - Shared lifetime: Reference counted with your choice of compatible container.
>
> These lifetime models are fully documented in the LuaBridge README:
>
> https://github.com/vinniefalco/LuaBridge


Thank you very much for the links!

During my searches before posting to lua-l, I came across 
https://github.com/vinniefalco/LuaBridge/issues/1 already, but somehow never made it to 
the starting page of LuaBridge.

I now carefully read the Readme on https://github.com/vinniefalco/LuaBridge, and must 
say that I like it a lot! As you say, it's lightweight and looks straightforward and 
very appealing to me.

Please allow me a few questions though:


  a) Can we store custom attributes in the Lua objects?
For example, in the Lua code in section 
<https://github.com/vinniefalco/LuaBridge#lua-lifetime>, will these statements be valid?

    a.temporaryLuaOnlyNum = 1.0;
    a.temporaryLuaOnlyStr = "hello";
    a.LuaEventCallback = function(x, y) ... end


  b) Will it prevent the garbage collection of "a" (my original problem)?
That is, if I run

    RefCountedObjectPtr<A> a = CreateA();

    push(L, a);
    lua_setglobal (L, "a");

then in Lua run

    a.LuaEventCallback = function(x, y) ... end     -- as above

    -- Some C++ function that stores a reference to "a".
    AddChildWindow(a)

    -- Artificial, but plausible if e.g. "a" was locally
    -- assembled in and returned by a function.
    a = nil

AddChildWindow() is some C++ function that stores somewhere in C++ code a 
RefCountedObjectPtr<A> to the given parameter "a", with the intention to call its 
"LuaEventCallback" later.

What will happen if Lua wants to garbage collect the now (for Lua) unreachable former 
value  of "a"?

While I see that even though "a" is gone from Lua, it would be possible to re-create it 
in Lua with the smart pointer (e.g. on the next "push(L, a);"), in Lua the re-created 
"a" would have foregone the a.LuaEventCallback, wouldn't it?


  c) If I implement a CFunction, how would I type-check a given stack position for a 
C++ class, and how obtain the related object?


  d) You write that std::shared_ptr<> etc. are not supported because of type erasure. 
(If I understood your description correctly, this is the very problem that intrusive 
smart pointers *don't* have?)
But, why do you place plain raw pointers in userdata?
Wouldn't the problem be solved if the userdata kept a *smart* pointer instance instead?


Your help would much be appreciated!

Best regards,
Carsten



--
   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
          Learn more at http://www.cafu.de