lua-users home
lua-l archive

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

Yes, I thought about that... the downside is that it would require a
little more effort on the Lua side (i.e when do you use the object
itself, vs lookup the ID), and I feel it is important to streamline the
Lua coding as much as possible, as it will be exposed to (advanced)
users, not just devs.  More streamlined == less documentation == less
support == happier devs :-)

And even so, I would still need to handle the situation where some
wayward Lua coder stores a reference (rather than its ID), which would
likely bring the whole game down if the script used it after the
underlying object were deleted.  I need to make sure that can't happen.

If you are interested, I explored some of the alternate strategies here:

http://stackoverflow.com/questions/1047212/detecting-stale-c-references-in-lua



Sean Riley wrote:

Another possible strategy is to store an ID rather than a pointer in the
userdata object. That way you can lookup the ID to see if the object
still exists, instead of dereferencing a pointer that may have been
free'ed.


-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
bounces@bazar2.conectiva.com.br] On Behalf Of Watusimoto
Sent: Monday, July 06, 2009 10:06 AM
To: Lua list
Subject: Re: Lunar, C++, and premature object destruction

Sean,

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.

Chris



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.



-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
bounces@bazar2.conectiva.com.br] On Behalf Of Watusimoto
Sent: Thursday, July 02, 2009 1:04 AM
To: lua@bazar2.conectiva.com.br
Subject: Lunar, C++, and premature object destruction

I'm working on a game that uses Lua to control robot players,

written

in


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


contains


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


intelligently


handled (probably by generating an error of some sort).  The

LuaShip

is


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

app crashes.

My questions are 1) Is this an appropriate architecture for

managing

Lua


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


examine


to see where my problem might be?

Thank you,

Chris