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