I use LuaJit for extending a plain C application (using the Lua C API). The host application does manage memory for a lot of objects that I have written wrappers for in Lua.
Now I would like to be able to delete objects from within the lua function, i.e. implement a delete function. I would like to illustrate the problem at hand with the following outline of the problem.
Basically my lua user data structure looks something like this.
struct my_lua_container {
size_t obj_db_index;
};
where obj_db_index is an index for the local object database. With the Lua C API I have created a lua-function query_object(...) that retrieves a lua metatable based on this user data and offering an API for managing the db object.
I am now planning to introduce a method my_db_object:delete() in the metatable API. :delete() could invalidate my_db_object by overwriting the variable with 0 or setting another member variable. The problem however is, that all references to the deleted object ought to be invalidated. Consider this lua code:
local p = query_object("1")
local q = query_object("1")
p:delete()
q:do_something() -- <=== q still contains a obj_db_index
Now I wonder how to solve this potential conflict. The two main problems are:
An invalid
obj_db_indexcould be an invalid index. This is actually probably caught by the code already, so it isn't pretty but alrightafter deletion, the index might be reused and this could lead to subtle errors when other references still use the old index.
What are strategies to deal with this?
My idea might be a little time-consuming but this would be ok in the event of deletion:
- Is there some Introspection that I can perform on user data objects? Like iterating over all user data objects with the same type in order to invalidate
my_db_indexwhen the deletion is triggered
query_object()to return differentuserdatas? In other words have it keep a (weak) table keyed on the argument and return the sameuserdataeach time. Alternatively have it return return different lightuserdatabut pointing to the same underlying struct. - Alex__gcthis might be doable. My other thought was to use some kind of an introspection feature to iterate over all userdata objects and check for existing user data pointing to the same object. - wirrbel