Re: [boost] Re: Re: Re: [prereview request][fsm]

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-28 03:32:51

----- Original Message ----- 
From: "Andreas Huber" <ah2003_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 27, 2004 11:55 PM
Subject: [boost] Re: Re: Re: [prereview request][fsm]

> E. Gladyshev wrote:
> > It does. The reason I asked is that
> > in #4, you are saing  that an exception renders
> > the state unstable (if I understood it right).
> > The definition of unstable state is
> >
> > "A state is unstable from the moment when it has been entered until
> > just before its last direct inner state is entered. Once a state is
> > stable it can only become unstable again by being the innermost
> > common outer state in a transition."
> >
> > So for the state to be unstable there must be an inner state.
>
> No, the term is "innermost common outer state", not "innermost state". The
> innermost common outer state is only defined during a transition and is
> exactly the same as the LCA, see definitions.html.

The definition of "innermost common outer state" is
"The innermost common outer state of two states is the first direct or
indirect outer state that
both states have in common".

It doesn't say anything about transitions?

In your watch sample, is the Active state is innermost common outer state
of the Stopped and Running states?
Are the Stopped and Running states are "innermost" states?

[...]
>
> This still applies in boost::fsm. If you don't define any reactions for
the
> exception_thrown event, your state machine will simply terminate when an
> exception is thrown. If you want to react to such exceptions you must
> explicitly define exception_thrown reactions. What makes you think
> otherwise?

I understand that.
My concernt is that your exception handing model has this internal
if/else mechanism.

"If the state machine is stable when the exception is thrown, the state that
caused the exception
is first tried for a reaction. Otherwise the outermost unstable state is
first tried for a reaction."

How do I incorporate this if/else behavior in my traditional state machine
design process?
For instance if I add an exception_thrown reaction to a state, how will I
know
whether this reaction is called as the result of an exception that occured
in this state or in one of its inner states?
How can I tell whether it is a failed react function failed entry action
of failed transition?

> > For instance if the state machine is in some state I can tell exactly
> > what events might have caused it and what state the client is in and
> > what
> > is the next possible state may be. My concern was is that if the
> > framework
> > is adding some *implicit* transitions upon exceptions  the above
> > explicit determinism is gone?
>
> Well, since the state machine is terminated when you fail to handle the
> exception_thrown event, you could argue that the exception handling system
> does add one reaction (the termination). Is that what you are referring
to?

Yes, plus those implicit transitions that depend on where the
exception is thrown (react/entry action/transition)?

It seems to me that with your exception handling process,
the well established state machine design techniques will need
to be revisited. I am not saying that it
is a bad thing, it just needs some theoretical work.
Like you mentioned before, all the FSM theories
aren't addressing the exception handling stuff.
You are suggesting a practical solution but a good
theory is absent.

Best,
Eugene