Maybe I'm not understanding something in your suggestion. As I understand it
it wouldn't matter if I used the metatable mechansim to automatically call
the Boehm garbage collector inside LUA. The Boehm gc has to search through
memory to verify that all allocated buffers are still reachable via some
variable/buffer in the workspace. To do that it has to do a tree walk
through all the pointers in it's root set and then all the pointers that
they point to etc. If I allocate a buffer that immediately disappears into
LUA it is completely unreachable by the Boehm garbage collector.
What buffer in the C data segment holds a pointer or a pointer to a pointer
et. al. allocated by the Boehm gc, that contains my C buffer now stored in
Lua? The Boehm gc has no idea what malloc/realloc is doing or what is in
the buffer created by these functions, thus it must eventually mark the C
buffer in LUA as unreachable and garbage collect it, causing memory faults
etc. Perhaps if LUA had key root sets on the stack or in some register, it
could avoid getting collected for a while. But my experience with this
suggests that it's not long before disaster strikes.
At some level in the garbage collector there is a flag that says that
memory/pointer/whatever is in use. This could be a reference
count or any number of things. When the pointer is sent off to
Lua it doesn't disappear as that reference still exists in the garbage
collector, having it exist in Lua counts as a reference to it (ie. it
should not be marked as free, because Lua has a reference to it).
Only when Lua collects the object would the reference that exists in
the C garbage collector be decremented/freed via the __gc metamethod
since Lua is no longer referencing it.
But I have never used a GC in C so I don't know specifically how your C
garbage collector works and therefore can't provide a more concrete
example.
--
// Chris
