Re: Moving from Lua 5.1 to 5.3 … (yet another multithreading discuss)

Another solution to the scheduling problem is to use luerl, https://github.com/rvirding/luerl , which runs a Lua inside the Erlang system. It is in fact implemented in Erlang. This gives you complete access to all of Erlang's concurrency and built-in pre-emptive scheduling. However, it also means that the Lua is not directly callable from C. Also it is only at 5.2 and not 5.3.

Robert

On 28 March 2018 at 13:22, Thomas Jericke <tjericke@indel.ch> wrote:

On 28.03.2018 11:38, Laurent FAILLIE wrote:

Thanks Thomas for your reply.

> Le mercredi 28 mars 2018 à 07:47:33 UTC+2, Thomas Jericke <tjericke@indel.ch> a écrit :

> It is possible to add preemptive scheduling to Lua >5.2 using hooks and yields.

Can you point me out some docs, examples, tutorials about that ?

The best description of my own solution is in the slides of my speak:
https://www.lua.org/wshop13/Jericke.pdf

Page 18 and following.

> But I would ask myself first, if you really need preemptive scheduling and in which situations.

> So my advice is, to look into a cooperative solution for your problem first.

My goal is to provide to end user the possibility to create Blockly like scripts which will be converted to Lua for execution (as Domoticz is doing).

The problems with cooperative approach is the scripts have to contains some explicite yield() which, de facto, impact the design of scripts themself, something I would like to avoid.

I thought that as well when I started. Currently I came to the conclusion that yields are seldom explicit in my code. Most of the time they are part of an API call.
That means, my API is built in a way, that every blocking API call yields and only stops the Lua thread and not the Lua state/interpreter.

Using real preemptive scheduling approach is an easiest concept :

* each task is focusing only on its jobs

* their scripts doesn't have to take care of what happening outside their own duty (shared objects access arbitration is already done at C side).

The other added value is a badly written script can't block everything (bad remembering of m$-win 3.xx era).

I know that problem. I am using a count hook to check if a script goes rogue. This doesn't work in all cases, but I can live with some responsibility for the scripter.
--
Thomas