lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Jul 21, 2004, at 7:14 PM, Mark Hamburg wrote:

You will also need to mutex around uses of the Lua API for each thread.
lua_lock and lua_unlock if properly defined will do this. You will, however,
end up with a lot of mutex overhead.
I'm afraid I don't understand how lua_lock would work in this context; 
I've only found references to it in older lua documentation, and there 
it seemed like a way to preserve a reference to an object.
What I'd like to be able to do is provide customized callback functions 
scattered through my threaded code.  I.e. Thread 5 hits a point where 
it wants to call computeComplicatedCoefficient(state) and get a number 
back.
I was thinking something like:

global interpreter lua_state LG: defines computeComplicatedCoefficient.

In thread X, get lock on the global state LG, create a thread state LT, release lock. Hopefully this would let other threads do their thing while I do something like:
lua_pushstring(LT, "computeComplicatedCoefficient");
lua_gettable(LT, LUA_GLOBALSINDEX);
push_my_state_object(LT, my_state_object);
lua_call(LT, 1, 1);

Where would locking go? Would proper locking prevent any other thread from creating a thread state LT2 and calling computeCC on its own? That would be bad.
I suppose I could just have one lua thread and set up a queue, but then 
I'd miss out on using multiple CPUs.
As you can tell, I'm still trying to wrap my head around how lua 
interacts with threads.  I guess I should just go spend a while reading 
the source.
-Johann