[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Replacement for unlocked refs?
- From: "J. Perkins" <jason@...>
- Date: Thu, 31 Jan 2002 21:38:02 -0500
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.