Re: Garbage collector issues

[Nicolas Devillard <ndevilla@...>]

> Lua 4.0 contains an undocumented function that does this and more:
>
> 	LUA_API void *lua_newuserdata (lua_State *L, size_t size);
>
> lua_newuserdata allocates a buffer of the given size and returns it to
> the user untouched, much like malloc, except that it uses Lua's
> internal malloc, and that the udata is added to the pool and GC is
> called on it; moreover it does take "size" into account for triggering
> GC.

Hum... that is an issue if your structure is a cascade of sub-structures
allocated by their own constructor (think of classes used in composition).
Is there any way of massaging lua_newuserdata to signal to the GC the
actual size of a userdata object? One solution could be something like:

LUA_API void lua_userdatasize(lua_State *L, size_t size)

which would assign the given size in bytes (to the GC) to the userdata
situated on top of the stack. You could then proceed with something like:

image * im = new_image(1024,1024);
which in turns calls a number of constructors like:
    im->history = new_image_history(0);
    im->data    = new_image_data(lx*ly);
    ...
which in turn might call some dedicated memory allocation routines.
Once this is done, you could push this new variable onto the stack, get
its size through an accessor you have written yourself, and signal it to
lua:

    lua_pushusertag(L, im, image_tag);
    lua_userdatasize(L, image_bytesize(im));

Another simpler way might also be to add an argument to lua_pushusertag to
declare the userdata size of it upon initialization.

I think that might be an interesting addition to the API, it would help
make Lua compatible with a number of existing libraries that already have
complicated allocation schemes you do not want to mess with.

Just my 5c...
Cheers
-- 
Nicolas