[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lunar, C++, and premature object destruction
- From: Watusimoto <watusimoto@...>
- Date: Mon, 06 Jul 2009 10:06:10 -0700
Thanks for your response. I may have found a solution just last night.
You are right that with Luna, the C++ code is unaware of any references
that Lua has to an object, so when C++ is done with it, it gets deleted,
creating the problem I reported. My solution was to rearchitect my
Ship/LuaShip relationship, such that there is no longer a one-to-one
relationship. When Lua wants a LuaShip, I create a new one, and let Lua
control its lifespan. I used a reference-counting pointer on LuaShip to
refer back to the Ship, so that if the Ship is killed and deleted, the
LuaShip pointer to it is set to NULL, and I can detect and handle that
situation when dealing with the LuaShip object. That let me remove the
pointer from Ship to LuaShip that led to the problems in my previous design.
The only drawback to this solution is that I end up creating a lot of
LuaShip objects (the Lua script may ask for several such references each
game cycle), whereas in my previous scheme, there was only one for each
Ship. But it does work -- Lua can hold or delete the LuaShip as it
likes, and C++ doesn't care; it will just create another when it needs one.
The only lingering problem I'm having is that while mucking around with
this, I found that some objects aren't being fully destroyed, leading to
a memory leak, but I think this is purely a C++ problem, and not related
to any of the above.
Sean Riley wrote:
Looking briefly at the Lunar code, I don't see anything that tries to
handle the case of the object being deleted from the C++ side. The only
cleanup appears to be when the object's associated userdata is garbage
collected from the lua side.
Maybe you could always delete the ship from the lua code? This would
require a wrapper function that calls into lua to nil out the reference
to the shup in script, causing it to be garbage collected.
From: firstname.lastname@example.org [mailto:lua-
email@example.com] On Behalf Of Watusimoto
Sent: Thursday, July 02, 2009 1:04 AM
Subject: Lunar, C++, and premature object destruction
I'm working on a game that uses Lua to control robot players, written
C++, and bound with Lunar, and am having problems controlling the
lifespan of objects created in C++ and referenced in Lua. (It's at
http://bitfighter.org, if you are curious, and the linked wiki
examples of some robot scripts.)
My primary object is a Ship. The lifetime of the Ship object is
completely controlled by C++. I also have a proxy object, called
LuaShip, that contains a pointer to the Ship, and handles all the
requests for information about the Ship from the Lua script. The goal
is that when the Ship is destroyed, the pointer on the LuaShip will be
set to NULL, and any future requests to the LuaShip can be
handled (probably by generating an error of some sort). The LuaShip
exposed to Lua via Lunar if the robot script requests it (using a
getShip() method or somesuch).
The Ship object also contains a pointer to its LuaShip proxy. My
problem is that when the Ship object is destroyed, C++ seems to think
that all pointers to the LuaShip are gone, and it is OK to destroy the
LuaShip as well. It does not seem to recognize when a Lua instance is
also referring to the LuaShip. The result is that the LuaShip is
destroyed, and the Lua script is now left holding a reference to
nothing. When the script acts on it (thinking it's still valid), the
My questions are 1) Is this an appropriate architecture for managing
instances that can have persistent references to C++ objects (Ship in
this case) that can be deleted without warning, and 2) are there any
good examples of code that uses Lunar in this manner that I can
to see where my problem might be?