[boost] [msm] Review

Subject: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-11-30 12:10:50

Hi Juraj,

First of all, thank you for being the first one to write a review. I
imagine it's not an easy thing.
Thank you also for bringing a few very interesting points to the
discussion. I'm happy to build on them and hope to finally start some
discussion.

>MSM does lack some of the SC functionality.
>There is no state-local storage in SC sense, as all states are
>constructed when main state machine is constructed. This can be easily
>worked around though.

As this point is being brought for the second time, I'd like to spend
some time on it.
You already have state local storage with msm, just not like with SC.
Like SC, msm defines states as classes, meaning they can have data.
There is however one important difference with SC. Msm builds all the
states upon state machine creation. States are not destroyed until
state machine destruction. This has advantages and disadvantages:
- states must be default-constructible
- you might need to heap allocate the state data if you cannot
initialize it at state construction.
+ speed: states don't need to be constructed again and again.
Constructing a state (and its attributes) each time it becomes active
can be costly, even if memory allocation can be optimized.
+ your state data is always available. In my experience, state data is
not only needed in the entry or when the next event is processed, but
during a transition or even at some time after a transition. This
means, that you have, during a transition, access to data from the
source or the target state.
+ combined with the visitor, you can at any time access data from the
currently active state and build a generic way to do something with
state data.
+ you can build examples like the iPodSearch where states keep
iterators to some container, thus keeping information from an
iteration to the next one.
+ you avoid having data released inside a destructor. Knowing that
destructors should not throw, it makes your life easier.
+ on_entry is templatized, giving you more leeway to add
event-specific handling.
+ your event data is not lost upon state entry

Msm's handling is hard to emulate with SC, on the other hand, SC's
handling is easy to emulate with Msm. It has its drawbacks but all
considered, I think it is a superior solution.

>It is impossible to stop event from propagation (SCs discard_event())
>without actually changing state.

It is true. At the moment you cannot. Actually, I don't think UML
foresees this possibility. OTOH, I think it is an interesting one and
will be happy to borrow it from SC.
I think that using the transition table is one of Msm's biggest
strengths so I offer to add a row or a functor allowing event
propagation to be stopped. You could even give it a guard, thus
allowing fine-grained transition conflict resolution.

> You cannot conditionally defer an event.

Again you're right. I think UML doesn't foresee this either, but I
also like it and will also borrow it from SC. You offered the idea of
a d_row (deferred row) or dg_row (the same with a guard). I think it
is the best possibility with the simplest front-end and makes deferred
events a first-class citizen, being in the transition table and coming
into play during conflict resolution. For the functor and eUML
front-ends I think it could be done as an execution row. Something
like:
State1() + Event1() / defer_()
Seems an interesting starting point.

>There seem to be some differences on how event deferral is handled when
> composite states are used. This part is a still bit mysterious to me.

I will add a part about the dispatch algorithm to the documentation.

>Aesthetically - I'm not a great fan of one big fat html documentation
> and would prefer to have it broken down and cross-referenced as most
> boost libraries docs are organized, but this is just a minor issue.

If Msm is accepted into Boost, I'd probably move to BoostBook anyway,
so this will be done at this time.

>  The author seems masochistic enough to try to tackle this. :)

Sure :) and I don't mind the term at all :)

Thanks for the review and the very good points you brought during the
last weeks!

Regards,

Christophe