Re: luaL_Buffer and 'exception safety'

["Dirk Feytons" <dirk.feytons@...>]

On 7/20/07, Ralph Hempel <rhempel@hempeldesigngroup.com> wrote:

> I think the luaL_Buffer() mechanism uses the C stack internally. One
> of the problems with embedding Lua is that you're never really sure
> how much stack you need, but at least you can look at the source if
> you're really interested.
>
> Your code could be written without malloc and use a small local
> array like this and achieve the same result as lua_Buffer() like
> this:
>
> static int get_data(lua_State* L)
> {
>   char buffer[LOCAL_BUFFER_SIZE};
>   int n = luaL_optint(L, 1, 512 /* some arbitrary default value */);
>
>   n = read_data(&buffer[0], n);
>   lua_pushlstring(L, &buffer[0], n);
>   return 1;
> }

That's essentially what I've got now but packaged in luaL_Buffer;
Mike's pointers were exactly what I needed. I could almost copy&paste
the code in liolib.c.

> I'm not a big fan of malloc() in embedded systems, but sometimes
> you have no choice :-)

Indeed, we are very cautious in using it. Malloc() is overrated :)
I still have to get used to the fact that calls to Lua may never
return due to an error being raised. This makes those rare cases where
you use dynamic resources tricky to get right when full blown userdata
is overkill.

> If you knew that get_data() was called from only one instance of a task
> then you could just allocate the buffer in BSS.

Indeed but that's not the case here. We'll just have to take the hit
in stack size of all the worker threads but in the end I think the
Lua-based solution will not exceed the stack usage of our current
code. Memory usage will move from stack to heap but even there Lua is
pretty efficient.

> Everything is a tradeoff...the fact that you can look at the
> Lua source and figure out what it's doing is part of why I like
> it so much!

True; so far I'm very impressed with Lua's elegant design and API
while still providing a powerful language.

Thanks all!

--
Dirk