David Abrahams wrote:
"Andreas Huber" <ah2003@gmx.net> writes:
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.
Here's one I'm pulling out of the air, since I don't have any real-world experience *with FSM exit actions*. I hope my extensive real-world experience with programs in general, state and invariant management, and error handling counts for something.
It certainly does.
A state X has a local buffer of data to be written to disk upon making a successful transition from X. The presence of that data on disk indicates something important about what's happened in the state machine, and you *don't* want the data on disk unless you have made the transition from X successfully.
Since most of my experience with FSMs comes from working with code generators that do not offer the state local storage feature, I would have written that buffer to the disk in a transition action, which is associated with all transitions leaving that state. With boost::fsm this means to move the buffer to transition context, which admittedly could sometimes look a bit arificial. Darryl Green had a much better idea: He would use a custom reaction to write the buffer to the disk and would afterwards initiate the transition (the whole sequence is therefore an in-state reaction immediately followed by a transition). This way the buffer does not have to be moved out of the state. Yes, this solution has the slight problem that one has to do this for all transitions originating at the state X. Although it can be done without duplicating any of the actual action code, one still has to explictly mention this for each transition in the reaction list of the state. However, and this is the main point here, well-designed real-world composite state machines tend to have very few transitions originating at each state. You often have one, less often two, rarely three and almost never four transitions originating at one particular state. Even if you have more than one reaction, IME it is unlikely that you want to save the buffer when any of them is triggered. My experience with FSMs mainly comes from controlling machinery and I have found the design patterns outlined above to be valid there. While I expect that they are also valid elsewhere, I cannot be entirely sure and that's also one of the reasons why I insisted on an example.
It would be a bad idea to write that data out if the FSM's controlling process decided to simply discard the FSM when it was in state X. Also, putting the instructions to write the data in a state destructor could require the otherwise-unneccessary quashing of exceptions from the function used to write the data to disk.
With the solution mentioned above this is no problem at all.
I said long ago that I was going to stop poking at this one, and didn't, because I had the sense that issues in this area, and the way you were reacting to my poking, might indicate that there were other problems.
I can only guess what exactly you mean with this, but it does sound like an accusation of me somehow evading your questions, see below.
I don't feel as though much progress has been made, and you seem to feel that trying to convince me of anything by example is futile.
I did provide one example many posts ago (the pump in the dishwasher). Also, let me quote what you had to say about this in another post: David Abrahams wrote:
I think a foundation for a decision is not flimsy when the behavior in question has proved to be useful in practice. So far nobody, who seems to have experience with non-trivial FSMs, has doubted that it is useful to terminate a state machine when it is destructed (my assumption A1).
I don't doubt that it's often useful. I also think it is surely sometimes highly undesirable. If you remove A1, the "useful" behavior is trivial to achieve without transforming the FSM, so it seems that a design without A1 is both more flexible and more orthogonal.
Since you don't doubt that it's often useful, why exactly should I then provide further examples in support for it? They will surely not convince that your "sometimes highly undesirable" assertion is invalid (that would seem highly illogical). BTW, I don't think that it is completely invalid either. What this all really boils down to is an interface that is easy to use and works well for the vast majority of the use-cases and requires workarounds for a minority of the use cases. I insisted on an example also to show how simple those workarounds can be and I doubt that they can typically even be called workarounds as they don't make machine design worse in any way (especially not with Darryl's trick).
So really, now I'm going to stop worrying this issue. May other peoples' posts be more helpful than mine have been!
Having slept over this and having spent pretty much the whole morning rereading our posts and reflecting on this whole discussion, I'm a bit at a loss what exactly went wrong. While I tried to always give accurate and to-the-point answers, you seem to have misunderstood them too often, what culminated in your accusation of me reasoning circularily. I don't want to imply that the problem necessarily lies on your side. In the beginning I definitely made the mistake that I assumed too often on what we would agree and what not. However, this alone couldn't possibly have led to the situation we now have. I don't have much of a clue what else I have done wrong. If other Boosters reading this have more of a clue then I would highly appreciate it if they'd let me know by private email. Regards, Andreas