[Interest] serialization of QStateMachine for recovery mode

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Fri Oct 11 07:04:33 CEST 2013

On Fri, Oct 11, 2013 at 12:05 AM, Ingmar Wegner <iwegner at gmx.de> wrote:

> Hi list,
> we are planning of using QStateMachine (excellent work, guys!) for a
> workflow driven application (tasks).
> I am thinking of an architecture in which tasks have their own state
> machine (QState) that will be connected to the application state machine
> (QStateMachine) as sub states. (Has anyone done something like this so far?
> ...I guess so!)

Yes, we have done something similar. We've used QSM as a UI controller for
our embedded Qt application. I think QSM is one of the best but most
underrated features of Qt! :)

> I am thinking of separating state machine logic from the implementation of
> the actions (e.g. data driven algorithms) that are triggered by
> transitions; so a task and a task_state_machine class for each task.

The way we did it was that each of our UI widgets used a represent a state
of the QSM, and would be 'activated' when the QSM entered that state (via
onEntry() and onExit() callbacks). For states that have more complex
interactions, you can have a child state machine further mapping the
sub-states. You can also look at having parallel state machines for
reducing the number of inter-dependent states (see the ex in QSM docs).

> Critical here is the feature to serialize the application state machine
> and the intended task state machines as I want to have a fallback if
> somebody pulls the plug (crash recovery)! Once the application comes back
> on it shall check for a possible crash and if so recover the state it was
> in before the crash.
> I couldn’t find any documentation / blog / forum question on this so far
> so here it is.
> Has anybody yet considered doing something similar?

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.

One "lame" way for restoring state would be to keep track of al the events
that were posted to the SM and sort of replay those events to the SM when
the app attempts a recovery (to reach the target state when the crash
happened). But this is not optimal as the event chain for a long running
app might be quite long.

> A fallback would be to rebuild the state by analyzing data that was
> serialized as regularly done for crash recovery.
> But this would make the state machine pattern complex!
> Any ideas / experiences?

What do you mean by 'data' here?

I don't think there's a way to directly jump to a nested state without
going through transitions from the top level state, but it's been a while
since I used QSM (used in 4.6/4.7) so I could be wrong here.


> Best Regards,
> Ingmar
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131011/8ce5308a/attachment.html>

More information about the Interest mailing list