Re: [boost] Re: Re: [fsm] Why exit actions must not fail

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-02 15:26:24

From: "Andreas Huber" <ah2003_at_[hidden]>
> Rob Stewart wrote:
> >>>> Is it? In the current design the state machine object owns the
> >>>> state objects (it does so for good reasons). How can you destruct
> >>>> the state machine object without destructing the state objects
> >>>> (and thus inevitably also exiting them and terminating the state
> >>>> machine as a result)?
> >>>
> >>> You're still collapsing separate concepts.
> >>
> >> The current implementation does. I don't think I did with the above
> >> reasoning.
> >
> > I read "in the current design...how can you destruct [sic] the
> > state machine object without destructing [sic] the state objects
> > (and thus...exiting them,..." as clearly linking the ideas.
> > (Points 2 and 4, above.)
> 
> I think you misunderstood why this particular discussion stared:
> 
> Andreas Huber wrote:
> >> Furthermore, it
> >> seems as though, if you want that behavior, it's trivial to get it by
> >> wrapping the FSM in a derived class whose destructor finalizes the
> >> state machine.
> >
> > Yes, but only at the cost of making the current interface (and
> > implementation) more complex (we'd need to have at least a separate
> > exit() function, right?).
> 
> IIRC, with "that behavior" Dave meant that a state machine is terminated on
> destruction. The rest of the argument then is about whether an interface
> change is necessary or not (and I still don't see how it could possibly be
> done without introducing exit()). But this isn't relevant anymore anyway,
> see below.

OK.  I understood Dave to be troubled by using the dtor for the
exit action and the issues that raised for managing exceptions.
He then was saying that if, for ease of use, a client wanted a
dtor to automatically invoke the exit() function, creating a
derived class with a dtor that does so is quite easy.  Thus, he
was arguing that requiring that the exit funcionality to be
invoked by the dtor was limiting and apparently made error
handling more problematic.

Anyway, you've been convinced for other reasons that exit() is
needed, at least in some form, so this is probably moot.

> > If destruction of a state machine involved no exit actions or
> > transitions, but merely released memory and other resources, and
> > similarly, if destruction of state objects involved no actions or
> > transitions, but merely released resources, then management of
> > those objects is simplified.  The library can impose upon such
> > objects that no transitions or actions are permitted.  This could
> > be handled by tracking a Boolean that indicates whether the FSM
> > was terminated and disallowing any further activity or by simply
> > saying, "I told you so," when things go wrong due to violating
> > that design tenet.
> 
> You've lost me here. Can you please rephrase what you mean with this?

I'll try.

Assume that the state machine dtor only releases resources, that
it doesn't do any FSM things like exit actions or transitions.

Assume that the library states clearly and emphatically that
state object dtors may only release resources, and that they may
not do any FSM things like exit actions or transitions.

Then, once the state machine has been halted (akin to
std::terminate()) for any reason, the library can disallow
further FSM behavior or it can just state that doing any such
things once the state machine has been halted results in
undefined behavior.

> > If exit of a state was separate from destruction, it could throw
> > an exception.  At that point, the state machine could be declared
> > unstable and could be forcibly terminated.  (Remember that
> > Boolean I mentioned?)  IOW, you could require that all exceptions
> > be handled specifically via an exception handler installed by the
> > client to turn execeptions into transitions -- I think that's
> > essentially what you've described thus far.  Any unhandled
> > exception can be treated like C++ does it: it calls terminate().
> > (In this case, I mean terminate() for the FSM so that nothing
> > more may occur.)
> 
> terminate() is the wrong word for that. In FSM terminology it is clearly
> defined what termination means.

I meant something akin to std::terminate().  I was drawing an
analogy.  Call it halt or anything else that works.

> > Ideally, we need more FSM experts to participate in this
> > discussion in order to bring their experience to bear on the
> > discussion.  It seems rather one sided right now (the experienced
> > FSM person on the side of the current design, and the less
> > experienced on the side that's questioning some design
> > decisions).
> 
> I think Darryl and Eugene are quite experienced FSM folks...

ISTR that they often qualified their own experience, but they
definitely have more than I.  Still, it would be nice to have
more to get a broader range of opinions or a stronger base of
consensus.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;