Re: Multithreading and locking...

[Victor Bombi <sonoro@...>]

Even without using lanes, you can start a different interpreter from each OS thread. The only problem will be thread communication but you can implement it in several ways with luasocket or ZeroMQ for example.

> > El 21 de mayo de 2019 a las 12:53 Francisco Olarte <folarte@peoplecall.com> escribió:
> > 
> > 
> > On Tue, May 21, 2019 at 12:07 PM Victor Bombi <sonoro@telefonica.net> wrote:
> > > Personally I prefer using lanes for running a different Lua_State in every OS thread (called a lane) and getting comunication between lanes with the lanes API.
> > 
> > My main problem is I do not have control of who calls the interpreter,
> > in heavily depends on runtime state. The app uses thread pools to do
> > it's work and sometimes calls back to my core logic in the
> > interpreter.
> > 
> > I've read of lanes before, reread it now and saw the first paragraph,
> > "Lua Lanes is a Lua extension library providing the possibility to run
> > multiple Lua states in parallel. It is intended to be used for
> > optimizing performance on multicore CPU's and to study ways to make
> > Lua programs naturally parallel to begin with. " I do not need, and
> > explicitly do not want, multiple states, and have no performance
> > problem, I'm going to use less than 1% of a single core in lua. Lua
> > code is going to control C code which goes in it's own thread pool,
> > just making the interesting high level executive decisions, not doing
> > the low level stuff.
> > 
> > > You say that
> > > > For a program I'm doing I need to use a single interpreter from
> > > > multiple threads.
> > > Are you sure you need a single interpreter?
> > 
> > I do not strictly need it, I can just code the core logic in C++ and
> > use zero interpreters, and reload dso for reconfiguration, or use a
> > shared data structure and shuttle data around and store interpreters
> > in thread locals, or use a lua interpreter for each thing. But the
> > problem I try to solve greatly benefits from a shared interpreter. The
> > lua code becomes easier. It normally just turns events into coroutine
> > dispatchs for handling some things, like IVR call flows, and
> > manipulates some global state for others, like a routing decission.
> > Having all this in a single interpreter means nothing moves while we
> > are inside lua, and the lack of syncing while inside means I get in &
> > out very fast, simple code, small bug surface.
> > 
> > But in some corner cases I MAY have to reenter. The typical case is
> > what I more or less told, I call a C function which sends a message
> > which ends up in another thread which wants to, say, read some data (
> > calling a func ) in the interpreter. Concurrency is not a problem. I
> > would like to do that by temporarily unlocking, but I think I can
> > manage it which yields, after all I'm going to have a dedicated C++
> > module for it, and encapsulate potentially reentering functions into
> > some objects having a before-unlock, unlocked, after-unlock virtual
> > methods. I want to just call them, but I think with very little
> > overhead I can code the interpreter entering code as a small loop
> > which handles LUA_YIELD and dispatch it using lua_yield() from some
> > stub transparently in the C++ side.
> > 
> > Francisco Olarte.