On Mon, Mar 14, 2016 at 9:54 PM, Sean Conner <sean@conman.org> wrote:
> If the code was purely Lua, then time_restricted_pcall() would be easily written. However, if any calls to C are made, then it gets complicated and requires system specific code to handle.
That is hardly different from a native application being blocked on a kernel call, and we all know that being able to break user-mode execution is still very useful for debugging. By the same token, it would be very useful to be able to break just the Lua VM when it is not running any native code.
We have debug hooks, which almost do the right thing with the "break on N instructions" feature, but they need to be set in advance, and choosing the N is not straightforward because it implies a performance vs responsiveness trade-off. It would be nice to have something like lua_break() that can be called on a Lua environment (which may be running some Lua code in another native thread), which would essentially call a user-supplied function before the next VM instruction gets executed, or at some other convenient VM execution milestone not very distant in future, in the original native thread.
Speaking of blocking native code, I do not think a fully generic portable solution is possible. Library writers, however, know (in principle) when their native code can possibly take a while (or block on a kernel call), and could then make that interruptible and/or cancellable. Then all it takes is a way to communicate to Lua that a given native function is interruptible/cancellable, and some convention to request interruption/cancellation.
