0

We're using some FSM library that allows you to define entry and exit actions.

For some reason, somebody needed to do this

fsm.Configure(State.A)
            .Permit(Trigger.A, State.B)
            .OnEntry(() =>
            {
                IsAuto = false;
                fsm.Fire(Trigger.C);
            })

This means that once the FSM gets the event Trigger.A, it will fire Trigger.C as part of the entry actions. Is that even correct?

This smells like a bad practice to me, but I would like to have a more academic answer to this.

SuperJMN
  • 443
  • It may be ok. The answer depends on when these triggers are processed, and what can they do. When these triggers are fired, are they processed immediately, or are they queued? If these triggers are processed immediately, can they cause an immediate state transition? – Nick Alexeev Aug 15 '22 at 03:37

1 Answers1

2

I'm not sure I have an academic answer, but I have used a few FSMs, so might share my experience.

The ability to have a single trigger cause multiple transitions can be useful. A real world example would be for controlling input in a UI program. Say I have a shape selected and click another shape, this could cause a transition to the unselected state, and then another transition to having the other shape selected. This can avoid the need to have transitions from each shapes selected state to every other.

Firing a trigger in an entry action could be one way to achieve this kind of behavior, but might not be the only, or best way to do it. But I'm not familiar with your specific library or use case, so I cannot recommend anything specific.

There is an obvious danger that doing multiple transitions on a single trigger event can cause infinite loops. So you might need to be careful when creating the FSM. One possible downside with using a trigger in an entry action is that it would be more difficult to analyze the FSM to check for such loops.

JonasH
  • 4,833