 |
lua-l archive |
|
|
||
|
| 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(), [1]. 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. [2]) 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? —Tim [1] Yes, I’m aware that the thrown error can be intercepted by Lua using pcall(), but I’m ok with that. [2] http://lua-users.org/lists/lua-l/2012-02/msg00060.html |