For what it's worth, I can provide the source-code for LuaThread. Since different threads running Lua code cannot execute simultaneously, there never was enough interest in the library. So I stopped supporting it.
Ah, I didn't realize LuaThread had that restriction. Then I'm guessing LuaThread was implemented more or less just by defining the lua_lock/lua_unlock macros (as Sean suggested)?
I have done some crude experiments, throwing caution to the wind and simultaneously running "lua_resume()" on a collection of different child states. For simple test functions, it does appear to work fine; and as I said earlier, I'm starting to suspect that there might be some relatively simple changes you could make in the guts of the interpreter that would make the approach more or less safe even while running more complex coroutines in parallel.
But, maybe my optimism about that is misplaced? Do you know if there are other areas of the interpreter that would need locking logic to make simultaneous execution safe, apart from table accesses, luaD_throw, luaC_newobj, and luaS_newlstr? Did you give up on true simultaneous shared-state execution because you saw some nasty collection of problems that I'm overlooking? Or was it just that table-access, by itself, looked troublesome enough to not dig into?
Thanks,
-Sven
