 |
lua-l archive |
|
|
||
|
Hello Gregg,I did a low level framework in order to build dashboards using MQTT / DirectFB and obviously Lua for user scripts : it uses intensively multi-threading with different State as well as interthreading data exchange and notification as you described :It is working pretty well and driving my smart home automation for months without a glitch.Notwithstanding, having this approach is creating lot of side effect in your code : as example, strings are stored in a lookup table that seems not shared among threads.So simple comparison like :if truc == "machin" ...may fails ... only of that.The more solid solution seems to me to patch Lua to allows multithreading (you have to define in lua's own code some function implementing locking and such ... sorry I don't have the link).I didn't choose this solution as I wanted to stick with standard Lua distribution as it is found in most Linux distribution (so without this patch).Best regards,LaurentLe vendredi 22 décembre 2017 à 01:24:02 UTC+1, Gregg Reynolds <dev@mobileink.com> a écrit :Hi folks,Thinking about writing a Lua binding for https://www.iotivity.org over the holidays. What could be more fun?But I'm a little worried about threading. Using the lib involves callbacks, each of which is on a separate thread. I.e. you pass a cb to the send fn, and the engine, when it receives a response, passes control to the call back, with the incoming msg as an arg, but on a new thread.My understanding is that I would just need to create a new Lua state for each thread, to pass to the call back.Seems reasonable to me, but it also looks like one of those things that turn out to be much more complicated than they seem. For example, if the same callback can occur multiple times, can I save one Lua state per callback and reuse it? And what if I want to share some data across threads?Any examples of this sorta thing out there? Any guidance appreciated.Gregg