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