Re: Multithreading and locking...

[Francisco Olarte <folarte@...>]

Viacheslav:

On Wed, May 29, 2019 at 12:29 PM Viacheslav Usov <via.usov@gmail.com> wrote:
> On Wed, May 29, 2019 at 8:34 AM Kaj Eijlers <bizziboi@gmail.com> wrote:
> > Wouldn't you end up with 99% of critical path inside mutexes and thus gain nothing from threading it since each task will be blocking on the next? (and if the answer is 'no, because the tasks do more than the lua access - wouldn't a message queue to the main thread suffice?).
> This reminds of a message I wanted to post in this thread but somehow never did.
> I, too, think that Francisco's problem could be dealt with using a single Lua state that runs in a dedicated thread ("supervisor"), that reads and dispatches messages from a thread-safe queue, and all the other threads send messages to this queue when they need to interact with the supervisor, rather than using Lua API directly.

It can be done this way, but is not that simple. Lua handles callbacks
which need to return data, so I need to send a message to lua and
block the calling thread while it works. Then I need to use a
reentrant message queue, so if a call the PI using an asynchronous
message to other thread I can process intermediate request. I mean,
API wants to send MA to lua and get RA. To generate RA lua needs to
call API with MB and get RB, and to generate RB the API needs to send
MC and get RC from lua ( all from the same state ). It can be done,
just a couple of queues and some changes in the architecture, not
complex, but not easy. As I said before, its much easier to just ditch
lua then and use C++ ( which I need to use anyway, to glue lua-core,
just change the interpreter instation and script loading to some
dlopen and calling ).

Francisco Olarte.