Re: [ANN] llua Higher-level C API for Lua

[steve donovan <steve.j.donovan@...>]

On Tue, Mar 11, 2014 at 5:27 PM, Jay Carlson <nop@nop.com> wrote:
> My feeling is that failure to unref is going to be a problem. Many people
> could use something like the Objective C pool-per-event, where their app
> top-level loop frees and/or complains about objects allocated but not
> explicitly moved to a long-term pool after each event.

It's always going to be an issue, because it's tied to intended
lifetime of references; it's hard for any system to guess when a
reference is no longer needed - unless indeed we're in some per-event
situation where you want to clean everything up not explicitly pinned
down.

Just for kicks, I've added llib/pool.c to llua, which provides a
rather similar concept for plain C.  llua objects are refcounted, so
if one can keep them in a container that owns them, unrefing the
container will drop them wholesale.  An llib object pool works like an
implicit reference container, so that any references created in the
body of this function will be cleaned up with the pool.

void do_something() {
    void *P = obj_pool();
    ....// llib, llua references created
    ....
   unref(P);  // all gone!
}

Anyone you wish to keep, increase the refcount using the ref() macro.

For adventurous souls, even possible to say:

void do_something() {
    scoped void *P = obj_pool();
   ....
   .... references created

} // at exit ref cleanup

This depends on gcc's famous cleanup attribute; this is also supported
by clang and later versions of Intel, so it's more portable than
people realize. It's convenient if you have multiple returns in the
function.

steve d