Re: Feature request: more integration of Lua and C memory management

[Luiz Henrique de Figueiredo <lhf@...>]

Jamie Webb wrote on Tue, 8 Jun 2004:

>Many libraries need to hold references to Lua objects, and to expose userdatas 
>to Lua code, and this creates a nightmare for memory management. Every object 
>must be either under the control of the Lua GC, or managed by the C code. 

Integrating Lua memory management with C memory management cannot be expected
to be simple, since Lua and C approach memory management in fundamentally
different ways: Lua has GC (and only GC) and C has malloc/free (and only that).

Having said that, I don't describe this integration as a nightmare. On the
contrary, I think that lua_newuserdata gives you the best of both worlds:
C memory that is managed automatically by Lua. If you still need to manage
memory from C, then GC metamethods are there to help you know when to release
C memory.

I've used both techniques in my libraries (which I write mostly to explore the
expressiveness of Lua and its C API). They are mostly bindings to existing
C libraries and so the memory management used in the binding reflects the
memory management used in original C library. If the C library does its own
management, then I represent the C objects in Lua by boxed pointers and set
GC metamethods to release them when they're no longer used in Lua. If the C
library does not create objects but rather uses user-supplied pointers to
structs then I use lua_newuserdata and do not set GC metamethod (that's the
whole point of using lua_newuserdata). This scheme works well. See lbc, lgdbm,
lmapm, lpdf for the first case and lgpc, lmd5, lrandom for the second case.

Of course, all this is simplified by the fact that C objects do not need to
know about Lua objects. Like I said in the beginning, hybrid memory management
is bound to be messy. (Perhaps this threadd is about the messy case and I've
chattering away needlessly...)
--lhf