-- Create a unique message buffer for each threadmsgs2 = {}msgs3 = {}-- Declare two unique functions for each threadfunction foo2() table.insert(msgs2, 777); endfunction foo3() table.insert(msgs3, 777); end

	mBarrier = new boost::barrier(3);	// The main lua state is initialize (mLua), create two 'sub states'	mLua2 = lua_newthread(mLua);	assert(lua_type(mLua, -1) == LUA_TTHREAD);	int lua2Ref = luaL_ref(mLua, LUA_REGISTRYINDEX);	assert(lua_type(mLua, -1) != LUA_TTHREAD);	mLua3 = lua_newthread(mLua);	assert(lua_type(mLua, -1) == LUA_TTHREAD);	int lua3Ref = luaL_ref(mLua, LUA_REGISTRYINDEX);	assert(lua_type(mLua, -1) != LUA_TTHREAD);	// Spawn two threads which use mLua2/mLua3 to call foo2/foo3	boost::thread thread2(boost::bind(&Sim::lua2Task, this));	boost::thread thread3(boost::bind(&Sim::lua3Task, this));	mBarrier->wait();

void call(lua_State* lua, std::string& func){	lua_getglobal(lua, func.c_str()); assert(lua_type(lua, -1) == LUA_TFUNCTION);	if (lua_pcall(lua, 0, 0, 0)) Aux::log(lua_tostring(lua, -1));}void Sim::lua2Task(void){	for (int i = 0; i < 10000; ++i)		call(mLua2, std::string("foo2"));	mBarrier->wait();}void Sim::lua3Task(void){	for (int i = 0; i < 10000; ++i)		call(mLua3, std::string("foo3"));	mBarrier->wait();}

Quote:Original post by ZealGamedev
I have two C threads, and two lua_States (created via lua_newthread(mMainLuaState)). I have a function setup that ensures correct data parallelism, so in theory thread1 and thread2 should be able to both call the function at the same time (the two calls have their own environment, and only read static read only globals). However, I am getting one crash after another (no helpful information provided in the logs sorry).

Quote:Original post by ZealGamedev
So youre saying I AM the first person to ever try and do this?

Quote:
Each thread in C which interacts with Lua will need its own Lua state. Each of these states has its own runtime stack. When a new C thread is started, you can create its Lua state in one of two ways. One way is to call lua_open. This creates a new state which is independent of the states in other threads. In this case, you'll need to initialize the Lua state (for example, loading libraries) as if it was the state of a new program. This approach eliminates the need for mutex locks (discussed below), but will keep the threads from sharing global data.

The other approach is to call lua_newthread. This creates a child state which has its own stack and which has access to global data. This approach is discussed here.

Quote:Dude, you can bargain with it all you want, you're not going to turn Lua inherently thread-safe

Quote:
threads write to the global_State quite frequently, even when you aren't operating on what you think of as "global data".

Quote:...This is why people who need preemptive threading in Lua tend to use separate global states.

Quote:Original post by ZealGamedev
Can you give an example? Can you point to where Lua is operating on the "global_State" in the example I posted?

Quote:

Quote:...This is why people who need preemptive threading in Lua tend to use separate global states.

Good thing I am not trying to do preemptive threading eh?

Quote:
You're calling table.insert, which internally invokes lua_rawset. This changes the size of the table, resulting in the memory counters in the global_State being incremented. Non-atomically

Quote:
Of course you are trying to do preemptive threading.

Quote:Original post by ZealGamedev
I see no reason why allocating local data needs to involve the global state (aside from garbage collection, but that could be solved in other creative ways).

Quote:What I meant is I am not yielding threads manually. I am running one thread per hardware core, and my task manager runs them cooperatively until all tasks are complete.