lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 16.06.20 18:04, Andrea wrote:
> One question: it seems llthreads2 does support Lua 5.3? and is it going to
> support Lua 5.4?
> From the description on GitHub this is not clear. I can read that it does not
> support Lua 5.0, and then I can guess that it does support 5.1 and 5.2 from the
> description of some folder.

I have automated tests that are using llthreads2 without problems under lua 5.1,
5.2 and 5.3. The llthreads2 rockspec file says lua >= 5.1, < 5.4 but I'm
expecting no bigger problems in using it under 5.4. Otherwise I would prepare a
pull request or an issue at the llthreads2 github page. Also all my Lua modules
are still specified as < 5.4 but I'm planing to lift them up to 5.4 in the near
future.

> Can you elaborate more on why LuaLanes was not the right choice?
> (complexity of APIs, functionality, performance, or other)

As I wrote: for me it was not basic enough. The API seems more complex than
needed for my purposes. For example just at the beginning of the documentation
it says a lanes.configure() function has to be called once. This puzzles me,
because it means that you must have control of the application startup (or state
startup?) and cannot use this in e.g. binary plugins containing Lua interpreter
that are in an host application, or a "Lua plugin" inside a host written in Lua
 that did or did not start langes.configure() before. Then reading further down
in the documentation I'm reading about "generator functions. Behind these there
are somewhere the threads. So you have to create a generator function, invoke
this and then you have an object that gives you return values as array members.
A more basic and straight forward approach just would you give a function to
create a thread like in llthreads2 with a start and join function (which in
principle is not much different, the difference here is mainly the wording and
the details). Then I also don't like how automagic upvalues are transferred to
the created thread function. IMHO it would be easier to understand if these
values must be passed directly. Then about Lindas: this seems to me a rather
complex machanism for inter thread communication. As far as I understand, one
could build something similar using Lua scripting code on top of mtmsg & mtstates.

So to summarize up my experience: Lanes seems to be a technical stable and well
tested solution which has a complex API that gives a lot of features. One could
write a wrapper around this to have a simplified view that would make it as easy
as wanted to use sub functionality of Lanes. However, I decided for me it would
be more fun to build up something from basic building blocks and also an
interesting challenge to find out how these basic blocks could look like and I'm
interested and open for discussions if these are the "right" (i.e. as basic and
simple as possible) building blocks or if some functionality is missing or if
another approach could be more basic and simple and result in even smaller
building blocks.

> Thank you very much. This is really helpful. Let me recap to see if I understand
> correctly:
> - Rings allow slave states to be created from a master state, basically a way to
> implement remote procedure calls, and there is the possibility to exchange date

I wouldn't call it "remote" since all Lua states here are in the same process.

> between master and slaves. There seem to be no mechanism for thread safety, no
> mutex. So the slave state can only be used in one thread.

Yes, in Rings there is no mechanism for thread safety, and, also important,
there is no mechanism how to pass a Ring state into another thread.

> - Mstates allow states to be created, and thread safety is guaranteed by mutex,
> so they can really be passed to one or more other threads.

Yes, in mtstates there is a mutex mechanism for thread safety and there is also
a mechanism how to pass a mtstates state to other threads (basically by just
passing the state's integer id somehow to other threads).

Best regards,
Oliver