lua-users home
lua-l archive

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


> Lua 4.1 brings a new API function
>   LUA_API lua_State *lua_newthread (lua_State *L, int stacksize);
> States created with this share the global environment with L, but have separate
> runtime data. (If L is NULL, lua_newthread returns a complete new state.)
> 
> There are also hooks for mutex: lua_lock(L) and lua_unlock(L), which are empty
> by default.

Well -- is the Lua state indivisible?  The problem with putting a single lock on the 
whole state is that is will very quickly become a bottleneck that exposes different 
threads to each other's implementations in terms of performance (i.e., there will be 
a big incentive to minimize global state access, even if the multiple threads don't 
otherwise interfere with each other.)  Also if you are performing read-only 
accesses, then in fact its ok to have multiple readers if there are no writers.  

So, in fact, you would prefer something like:

handle = lua_AcquireAccess (Lua_state, state_entry, access_mode)
lua_ReleaseAccess (handle)

I am not yet familliar enough with the implementation of Lua to know if all of these 
things are possible.  But you can specify this today and grow into them in the 
future on both sides: 1) In the first Lua implementation state_entry would always be 
0, or the start of the state or whatever and access_mode would always be equal to 
"READWRITE".  2) In the first C callback implementations lua_AcquireAccess would 
just grab a global mutex, and lua_ReleaseAccess would just release that global mutex.

> We'd like to see implementations of coroutines and multithreads on top these.

Hmmm ... my suspicion is that where people want this most is with multiple instances 
of Lua environments talking to some userdata implemented in C which also have client 
processes in the C environment (at least that's what *I* want.)  In which case the 
API you present (with or without my proposed modifications) should be sufficient for 
that.  I.e., people should be able to use real threads (not just coroutines) and use 
this.

Oh, BTW, this functionality is very cool.
--
Paul Hsieh
qed@pobox.com