Either I don't understand this, or I disagree. The state machine cannot be undercut by anything at all. Whatever happens to the rest of the module and the application - the state machine is in a state, which has defined a certain set of transitions it cares about (and how to react to each).
I don't want to sound academic or dogmatic, and I don't want to claim one of us is right and the other is wrong. These terms - sequence, state machine, QMH, ... - and implementations bleed into each other, and terminology is often used ambiguously in our bubble. So for the sake of this discussion, let's be very clear and academic:
You keep mentioning a sequence of actions. Our State Machine is not a sequencer - it has very little to do with how a sequence of states (or even actions) is or is not atomic. Also, this is not the intended responsibility of the State Machine module. It represents a stateful system, which reacts to different stimuli depending on the state its in. It does not care about the order of states and transitions (state changes).
I didn't mean about the state machine getting undercut, I meant about the MHL queue getting undercut.
I agree asynchronous text communication is difficult, especially with the fuzzy wuzzy use of the labels! Something about naming variables and cache invalidation...
Also, the State Machine is independent of and indifferent to whatever cases might be available in the MHL. Some of those cases might be triggered by the State Machine, or by other means, or both.
This is one key difference between your flavor and TLB'. In yours, as you say, nothing in the data of the module (MHL) directly influences the behavior of the state machine. This means that any data dependent transitions, i.e. branching, are decided on in the MHL and an explicit transition in the SM is requested (assuming one from the EHL didn't beat it there). In TLB', the state machine can receive a request/trigger for a state change but branch itself based on the module data. I feel that your implementation emphasizes a bit more the documentation aspect of the SM loop, where-as the TLB' SM is slightly more of an "active" thing, but that is very hand-wavey, gut-feeling interpretation at the moment. I would need to play with both in a more hands-on way to compare the strengths and weaknesses.
Of course you're right that DQMH does not guarantee atomic processing of multiple messages, hence the recommendation in the do's and don'ts that you already mentioned. If you want that kind of functionality, the other frameworks you mentioned make it easy(er) to get there 🙂
Yea. Previously I kind of clumped them all together in my mental model as "asynchronous, event-driven process" frameworks with either strict typing, JKI and DQMH using scripted events, or "duck-typed" as in Messenger Library, at least at the messaging level-- the user is responsible for passing the right type to extract-message-contents/variant-to-data VIs. I didn't however appreciate the difference between the developer responsibility of atomic message handling in DQMH and the more by-nature atomic action stack of JKI and Messenger Library.
Looking forward to your thoughts about this. Thanks for keeping me on my toes and forcing me to think these things through.
Glad to help 😁
