Boost logo

Boost :

Subject: Re: [boost] [MSM] event deferral and dispatching with base event
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-07-22 00:51:02

>> I understand it's bad. All I can suggest you is:
>> - do not create conflicts between an event and its base. I don't see how
>> this could be a right design.
>> - if you don't want event5 to come haunt you forever, stick to the UML
>> conform deferring inside a state unless you really know you will get no
>> transition conflict.
>Ok if I use UML like definition for the event deferral than at least
>event 5 is not getting dispatched each time thanks for that.
>And actually I can leave with the situation that even1 is dispatched 2
>times it only happens when no trans is taken in sub state machine so
>than it is not hurting.
>What I find disturbing that in this case the No Trans in not getting
>called ? Is it possible to fix at least this ?.

That no_transition is not called is actually normal as it's supposed to be
an error, or at least a warning. The no_transition handler is never called
on a submachine. Why? Because someone else might handle the event.
To handle an event, msm follows the UML rule of "deeper first", so Inner1
gets first a chance to handle the event. If it doesn't, RunningStateMachine
is tried. If it doesn't, SM1, and if it doesn't, then we get no_transition
on SM1.
An event is considered handled if a transition fires OR if a guard rejected
it. no_transition only means "hey you made a programming error, nobody had
even a chance to handle this". But you have a transition which handles
event1 because of your baseEvent catch-all transition.
Of course we are only a compile-time flag away from changing this but I
don't think you'll be happy with getting tons of no_transition calls in
Inner1 and RunningStateMachine for every event which was thought for SM1.

The real issue is actually the double call. I need to think about it more,
maybe there is a way for msm to handle this, I just didn't find it out yet.


Boost list run by bdawes at, gregod at, cpdaniel at, john at