[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: snapshot of Lua 4.1 (work)
- From: Paul Hsieh <qed@...>
- Date: Thu, 10 May 2001 01:48:25 -0700
> 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