lua-users home
lua-l archive

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

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.


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).

Jeremy J.