Re: [Boost-users] [MSM] a timer/timeout for the whole state machine (including submachines)

Subject: Re: [Boost-users] [MSM] a timer/timeout for the whole state machine (including submachines)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-04-09 16:19:51

Hi Albert,

> I've tried the pseudo-exit solution you've proposed and it worked as
> you explain, thanks!
> But, I'm still a bit confused...
>
> In your first answer you said:
>
>>  If the submachine doesn't handle the event, the upper one could, so it 
>> gets a chance to do it, etc. until the top-level fsm.
>>  If no fsm including the top-level fsm brings a no_transition, then it's 
>> a bug.

As I tried to explain in my last post, it turns out that I forgot the case 
where the event is generated on the submachine object instead of the 
top-level one.

> If I'm not wrong, now the no_transition is executed by the submachine
> (the 77840 fix),  but the upper state machine still doesn't have the
> change to handle the event.
> Is that right?

Yes. It is what I wanted to achieve.

> I'm not sure if this is the expected behaviour or not...
>
> In your first answer I've understood that the "upper-forwarding of
> events" was the correct behaviour (UML-conforming?), but after your
> fix I understand that events are not upper-forwarded:

There is no upper forwarding, we are talking about error handling and which 
entity should be the best to do it. From a user point of view, it seems to 
me logical that when I process an event on the top-level fsm, I get a 
no_transition handler called on this top-level fsm. I don't want a 
submachine to generate some error for an event the top fsm is going to 
handle right after (the UML Standard sees the priority of event handling be 
given to the "deeper" entity). It would only be a disturbance, right?
Now, if a submachine sends an event to itself (as you are doing in your 
added transition of the submachine), I also find it logical that the error 
handler be located there, this is why no_transition of the submachine is 
called.
That's why for this case, I needed to revise my previous position.

>> If you want to move to ErrorMode in the outer you will need either the 
>> ugly pointer
>> solution, or UML-conform, a pseudo exit.
>
> I've tried the pseudo-exit scheme in my Timer/TimeOut, but just to
> "emulate" the upper-forwarding of my TimerReset event.
> (I do not want to exit from my submachine, just an event to be
> upper-forwarded to the parent state machine)
> But I get an unexpected exception...

I would need to see your case to give an answer on this.

> I've returned to te ugly-pointer solution because in fact it seems to
> me a closer implementation to the upper-forwarding idea...

I didn't want to say it explicitly but the UML solution seems pretty much 
harder than the pointer, yes. But I wanted to give you the choice with a 
solution more in the spirit of UML.
As already said, several people asked for actions to get as parameter not 
only the current fsm but also the top-level one. I find it a good idea, I am 
just lacking time at the moment :(

> But, in fact, I don't really need "access" to the parent state-machine
> (nor the ugly-pointer ;-), but just that the events generated in the
> submachine's actions (but not present the submachine's table) to be
> sent/upper-forwarding to the outer state machine.
> Is this the expected behaviour or not?

If you want this, the correct way is to send the event to the outer machine. 
Either through the ugly pointer or through a peudo exit state.
I think the automatic forwarding would be confusing because, unlike the 
Standard, MSM sees a submachine as a full state machine in its own right, 
which can be reused in another fsm or as stand-alone. With automatic 
forwarding, this would be error prone as your submachine would react very 
differently depending on its context.
Again, better would be to give you the choice at which level you want to 
send the event. I think this will be done with a variadic-style template 
list of all the fsm's in a hierarchy for actions and guards. I'm not 
finished with the library yet ;-)
In the meantime, I apologize for forcing on you the ugly pointer.

Cheers,
Christophe