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

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-30 18:12:28

Darryl Green wrote:
> A state is considered left (and hence is destructed) only after exit
> and transition actions have run.
>
> That is, the previous state is destructed immediately before the new
> state is constructed. For nested states, all exit actions would run,
> followed by the transition action, followed by destruction of the
> states being left, followed by construction of the new state(s).
>
>> I don't see what that would buy you.
>
> Well it buys access to the state being left from the transition
> action for a start.

Right, but I don't think it is justified to complicate the interface and the
implementation (we'd need to add entry()/exit()) for that. As I've explained
in my answer to your other post you can always move such a variables into an
outer context that exists during a transition.

> In addition, if the exit action isn't the
> destructor, and it fails, you are still in the original state. A
> state specific recovery action is possible, using the state's own
> context. The state destructor still must not fail.

A state-specific recovery function would make error handling much more
difficult, as you have no idea what you need to do to bring the state
machine back into a stable state. If you e.g. make a transition from such a
state, it is not guaranteed that the machine is stable afterwards (see
Exception handling in the tutorial).

> My specific concern is the use of the extended functionality to
> produce states which have/build significant context that (should)
> only exist until a transition action deals with it. I don't see that
> using this state context after the exit action has run is a problem.
> The exit action may well have added to or modified it to make the
> context complete, not damaged (and in particular not destructed) it.

That's true, see above.

> I'm also concerned that the current fsm destruction/exit action
> implementation model results in an environment where I should avoid
> using exit actions that have any significant external effects because
> I don't want/expect them to be run when/if the fsm is destructed.

Concern noted. This is actually the central disagreement between me and Dave
Abrahams. If you have any real-world examples, I'd be *very* interested to
see them.

> Both the above concerns can be addressed by using custom reactions to
> implement "pre-exit" actions when/if this turns out to be necessary.

Yes. It becomes a bit cumbersome when you have multiple transitions
originating at the state though.

> I'll have to use the fsm library some more to see if this turns out
> to be the case regularly enough to make it a significant use case.
>
> So, I now believe that the library has the necessary flexibility, and
> only experience will tell how much and in what direction that
> flexibility gets used/stretched. I'll keep you posted...

Please do!

Regards,

Andreas