>Hi Christophe!
>
>...yes,
you told me that the submachines have no direct access to its parent state
machine. Sorry for the confusion...
No problem. I just want to make sure others will
not misunderstand.
>The reason why we are using a "global" event queue (each submachine
has access to it) is because we don't think that it is not a
>good design to call process_event from within a submachine: doing so,
we will lose the advantages of a hierachical
>statemachine design.
I admit I am not completely decided on this.
Ususally I prefer to give the submachine from outside a
boost::function or something equivalent or I exit the submachine with a pseudo
exit, even if I have to re-enter it. This preserves my encapsulation and avoids
a global queue, but I admit it is more work.
In any case, I need to provide a better solution. I
had no luck so far but I don't despair ;-)
>Further, how you will stop a submachine in case it calls permantely its
process_event method:
>doing so would cut the possibility to stop the complete statemachine
from the outside world!
I'm not sure I understand this. Permanently would
mean stack overflow, in any case, outside or not it is dead
;-)
>Our approach is to start an event collector, which is gathering
events from different sources and puts it afterwards into the "global"
>event queue. In the next step an event dispatcher pops the events from
our "global" queue of type std::queue <boost::variant <eventtype1,
eventtype2, ..., eventtype44>>
>and forwards it to to the process_event method of the hierarchical
Master or Slave state machines, which perform the appropriate transistions and
actions.
>Note: within one state an event can be put to the "global" event queue,
but it is in our opinion a bad design to call the process_event
>method of the current sub machine. We used the book" Practical UML
Statecharts in C/C++: Event-Driven Programming for
>Embedded Systems - Miro Samek" as basis for such kind of design( not
calling process_event event from within submachines).
>
>I would very appreciate your opinion regarding my
comment above.
I don't see why it would be bad design to call
process_event on either the outer or the submachine. But I didn't read this
book.
As long as the library makes sure that an event is
completed before the next one starts (which msm does), I see no
problem.
Furthermore, if calling process_event on the
submachine is enough for some events, you have 1) a more localized code (good)
and 2) a better performance (you avoid processing the event from the outer to
the submachine, so one process_event less).
But really, if you like the global queue, I don't
want to talk you out of it ;-)
There is no such thing as the Unique Perfect
Solution and I surely don't have it.
>Regarding the " out of memory problem": Today I've splitted my
library into two parts: one slave and one master shared library. So the slave
state machine does only now 20 events and the master knows 24 events.
>We have now a better compilation performance, but the memory allocation
is still big for master state machine: at the highest almost 900Mb memory is
being allocated while the compilation on windows.
>In comparison to the approach with a slave and master state machine in
one shared library we saved almost 400Mb memory allocation while compile time.
>This all is already compiled without debug information and it is still
a massive memory consumption.
Sorry, I know too little about compilers to provide
an answer, sounds strange that it makes a difference. OTOH 900Mb is not
unreasonable for heavily templatized code.
>Tomorrow I will have a look if I can reduce the number of events or
maybe even the number of submachines...
>
>Question: does the use of guards and actions in a
transition table also produce compilation time (template invocations)
>in boost.msm like with events? Please say no,
No :)
Seriously, no, I never found a measurable
impact.
>cause I still have to define actions and some guards into the state
machines.
>If yes, so we have ultimatively to decide if it would be better to
switch to another state machine library (state chart, etc.).
>Actually, I don't want this:)
Me neither ;-)
But clearly, statechart would compile faster,
yes.
Or you can give a try to favor_compile_time. With
so many submachines, it could help much.
>Br,
>
>Rafael
HTH,
Christophe