When starting my projects (as I said, Lua is used in several of my tools dealing with MQTT and smart housing), I made the balance b/w pros and cons : I decided to stick as possible with my distribution standard packages in order to make ownership easy to other people.
I'm using Gentoo and none of packaged version propose lua_lock() mechanism (even if I know it's quite easy to implement) and 5.1 was, and still, the proposed stable version.
Till now, even if sometime it's harder than expected, I've been able to keep dirty work in the framework itself (named "Toile") keeping "user side code" clean. In addition, I achieved almost all my objectives (lightweight, fast, open, clean, expandable, ...).
I will take such radical change only it I'm stuck and it would require strong modification and potentially would creates other issues : especially performances ones (because if Lua engine is requiring locking too often, it will void real time aspect, which is a critical point when speaking about IoT and automation).
More generally, there are ofter discuss in this list about Lua future : usual ":? is missing" is a gadget, but a clean and mastered threading capability is really a must nowday :)
Le Samedi 1 juillet 2017 23h48, Sean Conner <sean@conman.org> a écrit :
It was thus said that the Great Laurent FAILLIE once stated:
>
> I did good an nice thing with my application (I will publish a video of my
> dashboard soon :) ), but I think I reach the limit of Lua in a
> multithreaded environment :(
Have you thought of recompiling liblua with an implementation for
lua_lock() and lua_unlock()? That way, you can have a single Lua state that
can be shared among threads. And Lua is small enough that you can embed the
source within the project itself.
-spc
