lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 7/20/07, Ralph Hempel <> 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

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!