|I have a need to abort Lua states that are stuck in a compute-bound loop (e.g. "while true do end"). (And yes, “don’t do that” is a good answer, but I don’t have control of the entire corpus of Lua code running in the state).|
The best answer appears to be to adopt what lua.c does for handling signals: Do a lua_sethook() with a low instruction count and in the hook throw an exception with luaL_error(), . In my case, this code would be called by a distinct OS thread (not a signal handler), so I’m looking carefully at the thread-safety of lua_sethook().
The Lua source says that lua_sethook() can be called asynchronously, and I’ve spent some time reading lua-a archives (e.g. ) and studying the code. My reading of the source is that lua_sethook() *is* safe to call from a distinct OS thread (with some caveats), except i’m not clear about the code that manipulates L->oldpc in lua_sethook()? I’m not sufficiently familiar with the internals of the Lua VM to understand what it’s doing, and if it should be a concern or not?
 Yes, I’m aware that the thrown error can be intercepted by Lua using pcall(), but I’m ok with that.