Hi, I'm acutely aware I've been flooding your mailboxes recently, and all goodwill is finite! I have pushed some small doc changes to the QtQuickVcp repo. I've submitted a more substantial doc page to machinekoder's copy of the MK-doc repo - it basically reworks parts 2 & 3 of his MT explained series by adding some details around different messaging libraries. I went to the trouble of looking some things up, so I figured I might as well record that if it helps stop someone else using their time the same way.
I did this because it seemed that one way to systematically understand what MK/T does, and how it is done, is to understand its requirements. My thinking is: the requirements can be thought of as user or dev constraints. And also because it was interesting ;) Anyway, I do have some questions around MK's requirements. Rather than save them up and list them all at once, then have several conversations in one thread, I'll ask as they arise. I am recording what I do in a requirements page in the docs and will push PR's as I go. Anyway, to the point.... One MK/T requirement currently is: *Blocking and Non-Blocking Message Handling* *The transport library shall be able to send and receive messages in a blocking as well as a non-blocking fashion without resorting to cyclically polling for new messages to be available.* *Assumption 1: This only concerns messages between the RPC server and client. (Or does this apply to all messages passed between any MK/T components?)* *Assumption 2: The RPC client and server are described by the FSM* * rpcclient.dot and rpcservice.dot here [1]* *Assumption 3: These two FSM's are among a set of many more FSM's that must be implemented when creating a new language binding, as described here [2]. * Q1: Are these assumptions correct? That is, all MK/T messages must be via the RPC client/server, and these are described completely by the two FSM's in Assumption 2. Q2: Am I right that I can disregard the 'new'? That is, I also shouldn't have to poll for updated messages. Alt. there is no such thing as an updated message in MK and are all messages are treated as 'new'? Q2: Is there a requirement that callbacks be allowed to block to receive a message? If I understand correctly, this impacts the middleware implementation that can be used by MT. Again, apologies if this is irritatingly obtuse. If there is no requirement that the middle ware support blocking execution inside a callback while we wait on on a message, then it seems that the constraint on me is that I must not write callbacks (invoked by the RPC client/server) that block waiting for a message. Correct? Appreciate any feedback. [1]: https://github.com/machinekoder/machinetalk-doc/tree/master/machinetalk [2]: http://machinekoder.com/machinetalk-explained-part-5-code-generation/ Best wishes Hedge -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
