[IGSTK-Developers] State machine questions

[Kevin Gary]

Hi all,

I was looking at some of the state machine code to get
refreshed on the topic, and as often happens when I look
at code, I got confused ;).

In looking at SerialCommunication and base Tracker
classes, the sequence of calls for the Open methods
will first push an input to the SM and then process it.
In StateMachine::ProcessInputs, the function pointer is
traversed (toward the bottom of the method), and the
ensuing private method on the original object called.
The result of traversing the transition should leave
us in an "AttemptingToDoSomething" state. The private
method invoked (SerialCommunication::AttemptToOpenPort
or Tracker:: AttemptToOpen) then does a PushInputBoolean
based on the result of a virtual "InternalXXX" method call.

Some questions:

1. I do not see a call to StateMachine::ProcessInput(s)
anywhere after the PushInputBoolean (which queues an input
to the SM based on the outcome of the Internal method).
When is the queued input processed? Subsequent call to
the SM on the next request?

2. At the end of StateMachine::ProcessInput, the last 2
things done are 1) an execution of the transition, i.e.
the function pointer, and 2) setting the state of the
SM itself to the endpoint of the transition. If the
invocation of the function pointer itself leads to a
transition, then the call sequence will in fact "nest"
the invocation, meaning you will not end up in the
correct state. For example, in my hand-trace, it would
seem the SerialCommunication object would end up in the
"AttemptingToOpen" state and not one of the "m_IdleState"
(on failure) or "m_PortOpenState" on success. Of course,
question #1 may make this moot as I do not see when we
would ever traverse the 2nd transition (it seems to me
the only reason it works is because the Internal method
does the actual work *before* the PushInputBoolean call,
e.g. not under the guide of the StateMachine).

3. I am not sure of the utility of multiple queued inputs
to our StateMachines. As each input is mapped onto a single
transition in a given state, and the processing of a single
input should lead to a new target state, it seems that
a sequence of inputs queued on the basis of being in some
state will find the SM will not be in that source state
when the input is actually processed! For example, assume
I have a SM with 3 states, S1-S4, and 3 inputs I1-I3. S1
accepts inputs I1 and I2. I1 leads to a transition to S2,
I2 leads to a transition to S3. If I queue I1 and I2 and
then call ProcessInputs, I will have queued I2 believing
my object was in S1, when in fact it will be in S2 when
I2 is processed???

4. I am not sure of the utility of having the StateMachine
traverse two transitions and go through two states in this
call pattern. As we are assumed single-threaded (right?)
and these are private calls where the result of the original
client method invocation will never seemingly result in
being in the "AttemptingXXX" state...why introduce the
complexity? I'm not sure I see the benefit?

I also looked at the ImageSpatialObjectRepresentation, and
it does not do the "Attempting" type pattern, and so these
questions disappear (though it does validate input up
front to determine the input to push, instead of doing the
PushInputBoolean thing).

Sorry for the long narrative, it is involved code to trace
through by hand. I'm sure I am missing something...

Hope everyone has been well...

K2