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
