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

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-26 16:26:19

Rob Stewart wrote:
> Andreas made the remark that tying construction to entry and
> destruction to exit helps with scalability.  I imagine that means
> the he's worried about a potentially large number of states in
> some fsm's and that keeping all the state objects alive
> simultaneously could be a bad idea.

Ok, I guess I didn't express this clearly enough. When I mention scalability
I always refer to the fact that you can spread a state machine over multiple
translation units and that a change in one of these TUs will not trigger a
recompilation of the whole state machine. The two corner stones that enable
this are:
- State local storage. Every FSM object owns separate state objects. I.e.
state objects are *not* shared between multiple FSM objects (as they are in
some FSM implementations)
- custom_reactions

Whether or not states are also destructed when they are exited does not make
a difference here.

> If that's accurate, my
> question is whether this concern is valid.  How many state
> machines have so many states that are so large that they would
> cause appreciable memory problems were the state objects not
> destroyed upon exit?  I have no idea, and I won't speculate.

In some very constrained environments this might rarely be a valid concern
but I'd be surprised if someone chose to use boost::fsm in such a situation.
Don't get me wrong, I think it should still perform reasonably even on quite
constrained systems but for a few applications it will inevitably be too
slow/heavyweight.

Regards,

Andreas