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

[Thomas Jericke <tjericke@...>]

On 29.03.2018 11:28, Laurent FAILLIE wrote:

Le mercredi 28 mars 2018 à 13:23:19 UTC+2, Thomas Jericke <tjericke@indel.ch> a écrit :

> 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.

If I correctly understood, it's still not OS native threading isn't it ? But co-routines with some code to secure and makes their management easier, isn't it ?

Yes and no. I don't use OS threading to schedule the Lua threads. All Lua threads run in one C thread.
On the other hand, I would not call them co-routines anymore as the scheduler I implemented is preemptive.

But I'm thinking of another solution :

* A main Lua State that will only parse Lua source code and potentially run some initialization code before thread are launched.

* Then I create sub State using lua_newthread() and the corresponding State will be attached to a new OS thread.

As a consequence, all thread/State will share the same global objects (that will solve my issue about strings comparison I have will lua_newstate() ) but can run TOTALLY concurrently.

What to you think about this approach ? Even if slave States are not expecting to modify any global objects, do you think it is worth to implement lua_lock and lua_unlock ?

Thanks

Laurent

I can't give you a final answer as I never tried to use multiple C threads on the same global Lua state.
As far as Lua 5.1 and Lua 5.2 goes I came to the conclution, that Lua runs in the locked state for most of the time and therfore you wont be able to run the co-routines totally concurrently.

I would actually be interested in that approach, if someone has some experience with it.
--
Thomas