On Thu, Jul 3, 2008 at 10:07 PM, GaoXianchao <gxcmaillist@gmail.com> wrote:
> Hi Javier Guerra Giraldez ,
hi (just Javier, please :-)
> I have Another question on luathread:
Diego is the best one to answer the hairy details... i'm just an
interested observer of his code.
> If I call a c function which do something like calculating SHA1 hash of a
> large file in thread B, when I call another c function in thread A, it will
> be blocked or not? I see lots of "lua_lock(L)" in lapi.c.
plain Lua already has all these lua_lock()/lua_unlock() in place, but
these are macros that expand to nothing. LuaThreads adds the
infrastructure to make them useful. unfortunately, it's a single lock
for the whole shared LuaSpace; what is called GIL in other languages
(Global Interpreter Lock, same issue at least in Python, and probably
Ruby... Perl too? anybody knows?)
anyway, see ldo.c: where the call to C is done in luaD_precall().
there you can see the actual call is preceded by a lua_unlock(L), and
immediately followed by lua_lock(L).
IOW: the GIL sequentialises Lua, but when you call C, the lock is
released and other threads are free to run.
all the lua_lock()/lua_unlock() 's in lapi.c makes it safe to use Lua
C API from any thread, the GIL will be acquired as needed before
meddling with the LuaState.
--
Javier
