Manage C objects in Lua

Today, my colleague encountered a problem when designing the script interface of the engine: Put the C object pointer in Lua, and allow Lua to save the pointer and pass it to other modules. This is a common issue for writing C extensions to Lua. Aside from the more complex issue of how to import object methods to Lua, I mainly want to talk about the life-cycle management of C objects. The initial design was to import the object destruction method to Lua, which was manually managed by the script programmer. This is an obvious idea for C programmers: who constructs and releases the program. However, this is not suitable and does not conform to the habit of using GC language. ... Click to expand...

Today, my colleague encountered a problem when designing the script interface of the engine: Put the C object pointer in Lua, and allow Lua to save the pointer and pass it to other modules.

This is a common issue for writing C extensions to Lua. Aside from the more complex issue of how to import object methods to Lua, I mainly want to talk about the life-cycle management of C objects.

The initial design was to import the object destruction method to Lua, which was manually managed by the script programmer. This is an obvious idea for C programmers: who constructs and releases the program. However, this is not suitable and does not conform to the habit of using GC language.

We certainly hope that the script will be more robust without considering the issue of object release. So in the evening I thought about it and modified the implementation of this part.

Starting from the efficiency aspect, this problem is divided into two situations:

The first case is very simple. After the C object can be passed into the Lua state machine, logically it can ensure that its pointer is always valid. The program will not delete the object until the Lua state machine itself is closed. In this case, we only need to push the C object pointer to the stack in the form of lightuserdata.

The second case is that the C object is created or obtained by the script. After it is referenced, the object should be deleted to release the resources it occupies. In this case, we should use fulluserdata to register the GC meta Method for it.

However, the problem is complicated. The C object can be referenced by scripts or in C code. The reference Lua status of userdata in the script is automatically resolved. However, the gc process of Lua does not directly know whether there are references to objects in C. This is what we need to do.

The Python C interface provides related functions, which can be used to add or subtract and reference pyobject on the C interface. However, the GC of Lua is based on Root scan, and there is no reference count in the state machine. Naturally, Lua does not have similar C interfaces.

My solution is to create a weak table in the Lua registry (the value is weak, and the key is strong ), the C object pointer and the corresponding fulluserdata and the number of references in C are recorded in this table. Then, an API is provided to increase or decrease the reference count. When the reference count is 0, the table items about the count are cleared. GC can be used to recycle unreferenced C objects.

For detailed programs, refer to the Code posted on my wiki.

Here are some additional notes:

The GC meta method of all objects is shared, rather than creating a new meta table every time fulluserdata is created. This is a simple optimization that can save a lot of memory. For convenience, this metadata table is also placed in that weak table. Note: In Lua, every time you press a cfucntion, the memory will be re-allocated to create a new object. So we should try our best to share it.

Every time fulluserdata is generated from the C Object Pointer, the system checks whether it has been generated before. In this way, the reference count can be uniformly calculated.