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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-25 02:48:42

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:c8ogtj$npe$1_at_sea.gmane.org...
> Dear Boosters
>
> I think boost::fsm has finally reached a state that is worthy of a formal
> review.
>
> The .zip can be found here:
>
> http://boost-sandbox.sf.net/fsm.zip
>
> The docs are also available online:
>
> http://boost-sandbox.sf.net/libs/fsm
>
> As always: Feedback is highly welcome.

I've only read through the tutorial and glanced at the rationale, so bear
with me if I've missed something out. I have not looked at the
implementation. In brief it looks like some real good work has been invested
into the development of the library! Some personal opinions though (of which
I think some has been discussed otherwere in this thread):

1. No real support for runtime-defined fsm:s (yes, I've read the rationale).
This is something that I personally _could_ live without, but would prefer
not having to. I've definitely have had the need for (and implemented) a
totally runtime-defined fsm. The problem would be how to implement this
generically without the need for common interface classes ... hmmm.
<speculation/>How about implementing two models within boost::fsm (dynamic +
static model), or allow a hybrid approach?</speculation>

2. I'd prefer the states to be more loosely coupled (i.e. not having to know
about other states at the same or higher levels, or the fsm itself). The fsm
could take care of transitioning based on incoming events, current state and
the abstract "result" of the event[*]. This way the state transitioning
could be extended/changed without rewriting the states themselves.
Exception: outer states should have some knowledge about inner states (they
might be considered state-machines themselves). I guess by now my ignorance
of the implementation shines through -> are enclosing states actually state
machines already in boost::fsm?

3. The entering/exiting of a state is modeled by the
construction/destruction of a state object (see details in subsections).

3.1 Entering/exiting a state should be decoupled from creating/destroying
the state objects themselves. I can see the simplicity in creating the
states when they are entered etc, but for me states live continuously within
a fsm; they are just entered/leaved at certain points in time. And - if they
happen to be active states (i.e. run by a thread or running a worker thread
themselves) they might need to perform background activities even when they
are inactive.

3.2. The initialization of a state could be potentially expensive; needing
to initialize (construct) a state each time it is entered could result in
intolerable performance (consider a state needing to setup a TCP
connection). This could be handled in the current fsm implentation (I
believe) by keeping such things in the fsm or enclosing state - but there's
that coupling again.

3.3 I prefer (to the utmost extent) that initialization/construction is
performed once, which should be during the application initialization. Once
done, I'd like to know that my state objects (in this case) are constructed
and that the will remain so for the rest of the execution; no memory
allocation errors; no socket creation errors; ... etc .. during runtime
[basically the same as 3.2 above]. (aka "do or die").

4. Built-in support for active states would be great. Perhaps you've been
reading Miro Samek's great articles in CUJ (if not, please do so). Providing
at least some rudimentary (but expandable) support for active states would
be ... great (am I reapeating myself or what). <speculation/>Provide an
active_state base for states needing their own thread; provide an active_fsm
that keeps a worker thread that is running the currently active state (which
would require some cooperation from the states to implement transitions); or
... </speculation>.

5. If the dynamic stuff's never going to happen; perhaps provide an example
on how to implement a runtime-defined fsm on top of boost::fsm (you briefly
mention the possibility in the rationale) [related to 1].

[*] By abstract results I just mean some magical stuff telling the state
machine what the result of the "reaction" was. It could possibly be allowed
for a state to explicitly exit by using using the imaginary "return
exit_state(succeeded_result())".

Just my 0.05?.

// Johan