 |
lua-l archive |
|
|
||
|
Am 23.05.2018 um 17:05 schröbte Jeremy Jurksztowicz:
Hi, probably asked somewhere on the archive but my searches are turning up nil.
Hi!
Wondering if I can get any understanding of what kind of Lua code I can write that will not invoke the memory allocator. i.e. if I have a function that does not create any tables or strings, and I make sure that the lua_State has a lot of stack space, and pause the GC, and I only operate on numbers in a preallocated table, would it be reasonable to assume that the code would not block, and be suitable for signal processing? I have been looking through the code and docs, but if anyone can point to some definitive material or share some caveats or encouragement, I’d really appreciate that.
I have no definitive material for you, but I have looked into memory allocation patterns before and have some tips:
* Stack space is not the only concern. Lua allocates call frames for function calls. I have used a coroutine which yielded from a recursively `lua_call`ed C function to preallocate those. (Lua 5.1 is harder to handle because it doesn't allow yields from C functions, and it has different call frames for Lua function calls and C function calls.) * What you should definitely avoid is table literals, writes to non-existing table fields, new strings (e.g. using string concatenation, by implicit coercions or tostring calls, or some C API functions, e.g. luaL_error -- string literals in Lua code are fine because they are allocated when the chunk is compiled), new Lua functions, coroutines, or userdata. * You can replace the current allocator to check whether a piece of code allocates memory. * I haven't looked into LuaJIT, but I imagine that JIT compilation will allocate memory at the most inopportune moments. * If you plan to use Lua 5.4 when it is released, you should probably avoid Lua vararg functions (there are plans that those will allocate tables behind the scenes).
Regards, Jeremy J.
HTH, Philipp