On 29.03.2018 11:28, Laurent FAILLIE
wrote:
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
