Re: LuaThread sources?

[Diego Nehab <diego@...>]

Indeed. It was 2001 and the "lucky" among us had a Pentium 4... Threads were mostly used to hide latency accessing the network, or the hard drive (or to keep the UI interactive during computations). Giving threads exclusive access to the Lua state while they were running Lua code was not absurd back then. I wanted to avoid modifying the Lua source code, so the only alternative was to use lua_lock and lua_unlock.

If I were working on LuaThread today, I would try to make it more functional (map/scan/reduce) or like OpenMP (with pragmas), and modify even the compiler. :)

On Thu, Jan 3, 2019 at 7:47 PM Sven Olsen <sven2718@gmail.com> wrote:

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