Re: Threads HOWTO?

[Johann Hibschman <jhibschman@...>]

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