Re: Multithreading and locking...

[Victor Bombi <sonoro@...>]

So thats even better: Just start a different interpreter in each OS thread (as is recommended in so many places) and concurrency problems will be gone away.

> El 21 de mayo de 2019 a las 13:33 Francisco Olarte <folarte@peoplecall.com> escribió:
> 
> 
> Victor:
> 
> On Tue, May 21, 2019 at 1:07 PM Victor Bombi <sonoro@telefonica.net> wrote:
> > 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.
> 
> My problem is NOT thread communication, I have a C++ host, I can just
> have a shared & synced data, or do synced RPC to a singleton
> interpreter as I do in other projects. The problem is the raison
> d'être of lua is coordinating the working threads, it needs to make
> decissions and maintain and manipulate global state. In C++ it's easy,
> some worker needs a decission, calls in, I just sync on a global state
> object and if I need a potentially reentering callback I leave it in a
> consistent way, unlock, callback, relock, reexamine potentially
> changed interesting content ( which due to the dessign is generally
> nothing ), move along, finish work, unlock.
> 
> Doing it in lua means I can change control logic easily. Using
> coroutines means I can linearize event handling, I've done it in other
> projects, works quite well as their threading model means the
> interpreter is not reentered from another thread. But this ones as
> message queues and workers around, and sometimes I have this problem.
> 
> Francisco Olart.