Konstantin Osipov wrote: > We're desperately looking for ways to implement efficient lua_call() > and lua_pcall() timeouts. Yes, they are easily implementable with > a debug hook. However, running a hook on every instruction (or few > instructions) is not best for performance. Ideally, hooks which > check for timeouts need not have granularity lower than tens of > microseconds. You can dynamically set the hook from a signal or a different thread (lua_sethook is the only thread-safe call). To be effective with LuaJIT, you'd need -DLUAJIT_ENABLE_CHECKHOOK, too. But check the caveats at the end of lj_record.c. > Ideally, it would be great to integrate LuaJIT into our > virtual machine, so that it's possible to do a reduction (context > switch) while preserving the context of a running call. I'm not sure hooks are the best way to go then. Because they may interrupt execution *anywhere*, possibly in an undefined or inconvenient state (e.g. a lock is held). Often you can only abort then. And you have to be careful that the hook doesn't hit when you're in unrelated code. Prepare for lots of strange bug reports, caused by the non-deterministic nature of this approach. Much more reliable semantics (and better performance) will be achieved by polling a (shared) memory location with the FFI. So add this at defined places in your code (check_ptr is an int *): if check_ptr[0] ~= 0 then ... end Then you can safely do a context switch, e.g. a yield. --Mike