<snip previous discussion>

Thanks for getting me on the same page. I think completion events are peculiar only in the sense that their event is implicitly generated. Run-to-completion step semantics must still be obeyed as well as guards must be evaluated only once.

Yes, I agree on this. This is now the trunk state.

If the completion event has been dispatched and it fails to take a transition I believe the state is now quiescent (for reasons articulated earlier).

I also see it that way after re-reading the standard.

So... how do we exit? The *only* way to exit via the completion transition is for a completion event to be dispatched again. How can this happen? Via a self transition (or compound transition that returns) or via hierarchical search and a return to history.

----------- ----------- ----->| | [g] | | | S1 |--------->| S2 | -->| entry/F1 | | | | | exit/F2 | | | | |__________| |_________| |____| E

You are probably right from a Standard perspective (IIUC) but it is not a very elegant solution. Worse, those using completion events often write a complete state machine this way, and this method will almost double their number of transitions, which will cost much in compile-time.

I think executing process_completion is actually a violation of the model (UML). Completion events occur based on a well defined set of rules. Failure to take a completion transition because of a guard is by design or implementation (intentional or a flaw). A new event must be processed that results in a completion event to be dispatched for the evaluation to occur again. It also rubs me wrong because run-to-completion steps are always initiated via an event being dispatched. process_completion would produce a second "interface" for injecting behavior.

My recommendation would be to stick with the standard. Typically the side affects of entry F1 or transition E will result in the evaluation of g to true. If simply calling process_completion again results in g becoming true it means significant state changes outside of the state machine (or in a parallel machine). In my opinion, this would be an indicator of a bad design. The one place where I do something similar is when "polling" real hardware; however, I use the above configuration and trigger E to evaluate g in a predictable manner.

As msm is used in embedded systems, there is plenty of hardware and it seems a valid use case. Anyway, thinking about it again today, I realized that we do not need process_completion. I'm wondering how I could miss this. As completion events are defined for msm as having the event "none", the same effect can be achieved by simply calling: fsm.process_event(none()); And now we are UML-conform. We have our completion semantics for the first time the source state becomes active, and our standard event semantics using "none" as event. And this costs us no extra transition. Now this is a win-win scenario :) So, process_completion is out :)

As for the "wildcard" or any trigger, ROOM had this notion and I have used it extensively over the years. In 13.3.1 you will find AnyReceiveEvent. A transition trigger can be associated with this message event which would specify the transition should be triggered by receipt of any message. I don't think MSM encompasses the Communications Package models and this may be a stretch to get working.

BTW, MSM does not have the wildcard concept (yet) but is coming pretty close using a base event. If you define in your fsm an event called "any_event" and all your other events inherit from any_event: struct eventA : public any_event{}; struct eventB : public any_event{}; The following transition: Row Will fire if you throw at it an any_event, an eventA or an eventB. It's not perfect but it will help until I find a better solution. Thanks for your very useful insights! Regards, Christophe