Re: [BUG] LuaSocket is not thread safe

[Tim Hill <drtimhill@...>]

> On Mar 10, 2019, at 1:37 AM, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
> 
> 
> For now I've not seen any Lua implementation working successfully to run Lua states in concurrent threads. If this exists, there is necearrily numerous patches everywhere in the source base to add many declarations and specific code to control concurrent accesses and serialize them when needed (with mutexes, critical sections and some variables in thread local storage when we want to limit the performance cost of mutexes and serialization). As well, making Lua using fully concurrent threads can expose it to severe security problems (e.g. Spectre/Meltdown issues) and modifications in the compiler chain (e.g. using "Retpoline" workarounds): this is also a complex issue in other scripting languages (notably Javascript and Java) and simpler to manage if concurrency is done only with full processes (because this problem should be fixed at OS-level), for example when using pools of worker processes to run multiple Lua instances on application servers: concurrent threads would be performing better than concurrent processes. But the basic cooperative threads of Lua are much easier to secure.
> 

I think you misunderstand the OP. Lus itself is not multi-threaded, but IS thread-safe. That is, you can create multiple Lua states using lua_newstate() and run these in independent, concurrent thread with perfect safety WITHOUT any special patching or locking, since these two Lua states will not share ANY state at all. The OP was noting that, should you do such a thing, the library in question may fail since it is NOT thread safe. This is quite different from a SINGLE Lua VM running multiple threads concurrently.

—TIm