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
thank you very much for confirming this - it is reassuring that the packages are maintained
I had a deeper look at the packages and documentation - I have few more questions:
For mtmsg:
- What is the purpose of listeners? It seems a listener is used to listen to more than one buffer but it is not clear why one would do that. If I want to receive messages from multiple tasks/threads I give them the buffer id and they write their messages to that buffer, or not? The example in the documentation seems to indicate that messages are read in order by the listener, even if there are two buffers - so I guess one buffer could really do the job, or not?
- I found a minor spelling error in "This does not affect the underlying buffer, i.e. several buffer referencing objects could operate in different modes acessing the same buffer." by the way I had to re-read it multiple times to understand the meaning of that note. Blocking/non-Blocking is not a property of the buffer, but it defines the behavior of the function that reads the buffer, correct?
- abort: it is not clear to me what this does and why the abort operation can be canceled; what happens when abort is issued?
- references: it is weird that the listener does not keep a reference to the buffers it is listening to, why this is so? if the task/thread that is writing to the buffer ends, then there will be no reference from the writer, and the reader/listener should count as a reference, if not it may happen that the buffers are garbage collected and then what happens to the listener?
- only simple objects can be put into the buffer, no tables right? but one can send a string with the table construction which can then be executed from the receiver, right? this may be worth mentioning in the documentation...
For mtstates:
- What is the purpose of mtstates.singleton? it seems to behaves like mtstates.newstate when state does not exist, otherwise it behaves like mtstates.state returning an id; but I am not able to fully understand the note on the care to be taken to ensure reference counting is correct; why this does not apply to mtstates.newstate? for both methods, singleton and newstate, the isowner property would be true... can you make an example on when singleton should be used?
- states can be interrupted... therefore the role of mtint is not clear (at least to me - and I am sorry for that) can one contrast the interrupt operation here with the interrupt operation in mtint package? this again may worth be adding to the documentation...
Andrea
