[Interest] serialization of QStateMachine for recovery mode

[K. Frank]

Hi Mandeep (and Ingmar)!

On Fri, Oct 11, 2013 at 12:37 PM, Mandeep Sandhu <> wrote:
> Adding Ingmar to the loop... :-)
> On Oct 11, 2013 6:59 PM, "K. Frank" <> wrote:
>> Hello Mandeep and Ingmar!
>> On Fri, Oct 11, 2013 at 1:04 AM, Mandeep Sandhu
>> <> wrote:
>> > ...
>> > I don't think QSM provides this feature. The thing is that you might
>> > have
>> > arrived at the current QSM state after a some set of events and
>> > transitions
>> > when the app crashed. It'll be quite an overhead to store all this info
>> > in
>> > the QSM, especially if history states were involved.
>>
>> Just a side comment here:
>> ...
>> If you've gone to the trouble of designing your program around a
>> state machine, you might as well take advantage of the benefits
>> of the state-machine approach when you implement your
>> persistence and recovery.  If you've been disciplined about keeping
>> to a relatively pure stater-machine design, then, in principle, you
>> should be able to persist -- and recover from -- just the formal
>> state (and extended state data).
>
> Let's take a over-simplified SM.
>
> A->B->C->D
>
> now if the app crashed while it was state C, on restarting the app, I don't
> see a legal way of directly taking the SM to C, other than replaying the
> events that caused transitions to it.
>
> Or is there some other trick to it?

First, I won't speak to the details of the Qt state-machine
implementation (because I don't really know them).

I wouldn't call it a trick.

It's reasonable to imagine that your state-machine framework
can do something (or can be modified to do something) like
this:

   myStateMachine.state = stateC;

or

   myStateMachine.setState (stateC);

So, schematically, your code might look something like this:

   if (normalMode) {
      startEventLoop();
   }
   else if (recoveryMode) {
      myStateMachine.state = stateC;
      startEventLoop();
   }

If your state-machine framework won't let you do this, or if you
prefer to live within the formal approach of events and transitions,
then you could add some helper events and transitions to your
state machine.  Let's say that your state machine gets initialized
to startState.  Then you could add:

      event      transition

      goToA:   startState --> stateA
      goToB:   startState --> stateB
      goToC:   startState --> stateC
      goToD:   startState --> stateD

Then at startup, if you're in recovery mode, you would do
something like;

   myStateMachine.postEvent (goToC);

(But I would probably consider this overkill, and just
implement making "myStateMachine.state = stateC;"
work.)

> -mandeep


Happy State-Machine Hacking!


K. Frank