Re: LuaThreads with LuaJIT (and maybe lua_tcc)

[Mike Pall <mikelu-0604@...>]

Hi,

Jerome Vuarand wrote:
> I'm working on a project that absolutely require premptive
> multithreading (multiple hardware threads are available) and
> some good runtime performance.

Then LuaThreads is not what you want. Apart from performance
reasons (see below) there is a serious limitation: there is only
a single lock around the Lua core. This means that only one
thread at a time can execute Lua code. A thread can only run in
parallel if it is executing C code which does _not_ call back
into the Lua core (i.e. blocking in an I/O operation or some CPU
bound C code).

I suggest you look into the mailing list archive for other
approaches. You can use multiple Lua universes and connect them
with message queues. Or you can use helper threads to do some
isolated CPU bound operations in C code (only accessing the Lua
core at the start and end).

Or you can use purely non-preemptive coroutines. It's inherently
single-threaded, though. This is sensible for most I/O bound
apps. You can run an app multiple times if it is CPU bound or
just rely on other processes keeping all CPUs busy. Avoids the
"mutex hell" of preemptive programming, too.

[Note that all of this is not a flame against LuaThreads. It's an
inherent limitation of the concept and not the implementation.]

BTW: There is another approach which avoids most of the lock
overhead. But it requires active cooperation on the C side and
you can't use the current lua_lock/lua_unlock macros:

  Basically the universe lock is held all the time, even when
  crossing the Lua/C boundary. All I/O operations which could
  potentially block need to be wrapped with an unlock before the
  operation and a lock after the operation. Ditto for very CPU
  intensive operations (like an RSA computation). This means you
  need to modify io.* and any other external library which may do
  some I/O (like LuaSocket).

  Then you can either choose to use active preemption (requires
  explicitly calling a no-op function which unlocks/locks) or
  modify the main VM loop to unlock/lock after a certain number
  of bytecodes. The former is easier for I/O bound code and you
  can avoid locking global objects, too.

  This is basically the same as the Python GIL approach. See
  their archives for a discussion of the advantages and
  disadvantages.

> I use custom Makefiles and was used to build a lua.dll and
> lualib.dll pair instead of a single lua50.dll. With Lua 5.1 I had to
> patch some files to allow seperation of core and lib.

Umm, why? There is no functional reason to do so. That's why this
was dropped for the Lua 5.1 Makefiles.

If you really want to keep backwards compatibility to Lua 5.0 (I
don't see the point for a new project), then it's considerably
easier to change the Lua 5.0 Makefiles to use a single library.

> - did somebody achieved to make LuaThreads and LuaJIT coexist in the
> same build (even experience with 5.0.x would help me) ?

This is a lot of work. You'd need extensive modifications to
LuaJIT to catch all cases where the core is left/entered or where
the lock needs to be released temporarily for loops.

> - are there some expected fundamental issues or incompatibilities that
> would theoretically prevent me from using LuaJIT and LuaThreads together
> ?

LuaThreads may seriously slow down your application because of
the excessive mutex overhead. Every C function needs a few calls
back into the Lua core and each of them locks/unlocks the mutex.
Just registering the standard Lua libraries (luaL_openlibs)
requires more than 1100 locks+unlocks! The heavy lock contention
is bad enough for single CPUs and will slow everything to a crawl
on multi-processor machines.

LuaJIT is there to speed up your application. Using it together
with LuaThreads would be rather pointless since you'd loose much
of the gain.

> - did somebody achieved to make LuaJIT and lua_tcc coexist ? (I haven't
> tried yet since I have problem with tcc relocation, but I guess two
> relocating runtime compilers in the same dynamically linked process may
> not like each other)

I have not tried, but I do not see a problem with coexistence.
Both compilers manage memory on their own and should not get into
conflict. But read Javier's post, too.

> - did someone achieved to seperate LuaJIT core and lib code ?

See above. IMHO there is no point in trying. You need both
anyway.

Bye,
     Mike