Re: Lua and preemptive scheduling for coroutines

[David Heiko Kolf <kolf@...>]

Leo Romanoff wrote:
> ----- Ursprüngliche Message -----
>> Von: David Heiko Kolf <kolf@gmx.de>
>> An alternative to using Lua hooks might be to copy the Lua parser into
>> an own library and patch it to include a call to yield at the end of any
>> loop (and in Lua 5.2 for any goto that jumps backwards).  The debug
>> hooks might be more efficient for small loops with high repetition
>> counts though.
> 
> This is interesting, David! This would be the exact equivalent of a byte-code instrumentation approach for Java, which I mentioned before,  which would inject conditional yields. 
> Any idea how difficult would it be to put the Lua parser into an own library? Would it mean building my own Lua binaries by substituting standard parser by the patched one? Do I need to include calls at the syntactic level or in the internal representation (e.g. abstract syntax tree, bytecodes or whatever is used by Lua)? Would it also work for LuaJIT? Or should I patch both?
> 
> -Leo

I wouldn't modify the Lua library itself but instead copy the code
starting with the API function lua_load into an extra module.  (Renaming
all the copied functions).  This way the standard load function still
works as expected.

Depending on how you solve it, you might get certain incompatibilities.
 I think LuaJIT (at least 2.0) has an own bytecode format so it wouldn't
work with bytecode generated for the default interpreter.

Then you also have to consider whether you can (and want to) access the
internal Lua functions when implementing your own load function.  The
cleanest solution using just the API functionality would also be the
hardest as you would need to serialize the functions and read them again
using the API lua_load.

The debug hook might be the easier (and more efficient) solution.  If
the goal is just to prevent a broken user script from tying up too many
server resources (or screwing other clients) I probably wouldn't even
bother to inject yields but just raise an error when the runtime limit
for a coroutine was exceeded.  Then the user can pick the optimal places
for yield statements without having to worry about being interrupted at
the wrong time.

-- David