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: Albert Gil Moreno (albert.gil_at_[hidden])
Date: 2012-04-10 06:57:41

Hi!

> There is no upper forwarding,

Ok!
Now it is totally clear to me!
;-)

> we are talking about error handling and which entity should be the best to do it.

Well, in fact in I wasn't thinking about error handling...
I was using an orthogonal region for my Timer state/class, not as an
error handler, but as a "no activity handler"... ;-)

My problem arise when the "activity" is generated/processed in a submachine.

Probably I should rethink my design:
- A Timer inside all my (sub)state machines?
- An independent state machine only for the Timer and (not so ugly)
pointers from/to it in all my (sub) state machines?
- More work on the pseudo exit?

I've to think and try them...
If you are curious, I'm sending a version my Timer (without the
threads and other noise I'm working on)...

> 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.

Sure you are right, but probably because I'm completely newbie on UML,
I see the "no_transition" handler as a kind of "exception cached",
which is more familiar to me... ;-)

For this reason I could think that a (sub) state machine could handle
some "no_transitions" for some events (some cached cases), but it can
also auto-upper-fwd them to the parent state machine...

But this is totally out of the scope of my Timer goal, and I've to
remember: there is no upper-fwd!!
;-)

>> But I get an unexpected exception...
> I would need to see your case to give an answer on this.

Don't care!
I should work more on it!
Thanks!

> 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 :(

I know, it will be great, thanks a lot for your time!!
:-)

> 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.

Sure you are right again, but...

I mean, I like very much the idea of full state machines and to
reusing them, and states, events and actions, of course!
In fact I'm trying to follow this idea as much as I can!

But I don't think that the automatic forwarding would be "confusing",
but the "natural behaviour" of a state machine (?).
(again, I don't known UML, so I'm probably wrong!!)

The upper-forwarding seems as "natural" to me as when the upper state
machine receives an event that is inner-fwd to the active submachine.

Probably, because I'm not familiar with UML, but I am with exceptions,
I see events like a kind of exceptions (generated somewhere...)  to be
cached starting from the nearest active (sub)state machine (nearest
caller) and upper-forwarded until the last/outest state machine (main
function).

In fact, in my case I wasn't thinking on terms of full-machines vs
sub-machines, neither in forwarding...
I was just thinking to implement a reusable functor-action
(Timer::Reset) to be placed in any transition table.

This functor action doesn't know anything about the
(sub)states(machines) and events which produce its execution (totally
reusable), but they just send a specific event with the hope of being
cached for some "friendly" state/orth.region (Timer) running in
parallel somewhere, or (if no one catch them) to be just ignored in a
no_transition function.

But probably this is not the UML-way to design (?).
(again, and only if you are curious, take a look to the attached
implementation...)

> In the meantime, I apologize for forcing on you the ugly pointer.

Come on!!
With MSM a have just one ugly pointer, but without msm... sure I've a
lot of ugly sm code!! ;-))

Thanks a lot Christophe,

Albert