[Qt-interest] Initializing application modules in sequence

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Mon Apr 25 15:41:31 CEST 2011


> It sounds as if QStateMachine would be a good candidate here. We do
> something similar with hardware devices (usb or Ethernet based).

That was my initial thought too... :)

We use quite a lot of QSM's for controlling both GUI and non-GUI
components of our application.

>
> * Asynchronous initialisations can also be handled naturally too since
> the SM operates via the owning thread's event queue. In this case, the
> subsystem state may have additional child states. Perhaps one for
> sending out a network request and another that gets transitioned to upon
> a network response. This allows your receiving/processing state to
> verify the response was successful. Then you either emit a custom event
> indicating success or failure.

Won't async/non-blocking init's require some sort of a parallel state
group? Take the following init steps eg:

1 (B) -> 2 (B) -> 3 (NB) -> 4 (NB)
                       +-> 5 (B)


B=blocking
NB=non-blocking

In such case I could add states/transitions depicting the steps as :

1 -> 2 -> 5 and 3 and 4 should be performed in parallel after 2 is done.

However, for steps 3 and 4, I'd like to start them the moment step 2
is done. 1 way is to add a sub-state to state 5 and a parallel state
group with 2 parallel states representing steps 3 and 4. So both of
them (3 & 4) will be started when we enter state 5

I found using SM for such init routines a little rigid. It also
requires one to change the SM each time a new/different sequence of
init's is required.

Another thought that I want to bounce off others:

* Have a controller class...say InitManager (initmgr for short).
* All modules that need initialization implement an interface so that
the initmgr has a uniform way of talking to, with all modules.
* Modules register themselves with this class either in blocking or
non-blocking mode.
* For blocking mode, they are invoked in the order in which they were
registered, each time initmgr waits for a signal from the module which
indicates init completion.
* For non-blocking mode too they are invoked in the order in which
they were registered, but the initmgr does not wait for init
completion.
* Final completion is assumed when all (B & NB) modules have signaled
successful completion.

To keep it simple I've removed the requirement of having a
'dependency' though. In case a module 'C' requires module 'A' to be
done before, then 'A' must be made blocking and 'C' should be
registered _after_ 'A'. So with this limitation, all modules which do
not have any dependencies can be marked as non-blocking and others as
blocking.

With this approach I can also give out some sort of 'x percentage
completed' signal to a user who might want to show the init progress.

> Hope that helps but feel free to come back with more questions if
> anything is not clear from those ramblings ;-)

Your 'ramblings' are very valuable (my understanding of QSM was made
easy by you and others on this list). Thanks again for your input!

-mandeep

>
> Sean
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>



More information about the Qt-interest-old mailing list