 |
lua-l archive |
|
|
||
|
Diego Fernandes Nehab wrote:
Last try... I think we missunderstood each other. :-)
[...]
My suggestion is that you use the userdatum directly to reference the object from Lua. You can create an associated table and place a strong ref to it as a field in the C++ object. You set the gettable and settable methods for the userdatum to access the associated table. You set the garbage collection method to unref the associated table. (there is no self field in the associated table, there is no cycle)
There are still some synchronization problems with this approach, though they too could be worked around. Say I have a component, which has both Lua and C++ parts. The C++ part is being reference counted.
Lua could hold a reference to the object while the C++ refcount goes to zero. At this point I could let it sit around until it's GCed.
Lua could try to GC an object whose refcount > 0. I can't release the Lua table because the object could be passed back into Lua later, and I don't want to lose any information that's been stored there.
So say I have a C++/Lua object. The userdata gets GCed, but I ignore it because the C++ refcount > 0. Now I make a call into Lua and pass my object in as a parameter. The call returns, and the C++ refcount gets decremented to zero. Can I delete the objects? C++ no longer needs it, and Lua tried to GC it earlier. But Lua could have kept a reference to the table when I made the Lua call. Or maybe it didn't.
I do understand you're approach and it does work, but it assumes that Lua "owns" the object, which is not the case in this instance. I really need the ability to store both weak and strong references, which I can get with a pair of tables in my scripting interface (although...well, I think I made my case earlier).
Thanks for knocking this around with me, I hadn't considered your approach before and it did get me thinking.
Jason