Good taste design question about nested FSMs

[Ulf Wiger]

On Fri, 17 Dec 2004 07:45:05 +0200 (EET), Jani Launonen <jabba@REDACTED>  
wrote:

> So --- finally --- the question is; apparently I should ditch the
> gen_fsm and make my custom fsm that can be attached to the supervisor
> tree (by using sys and proc_lib), so that I can make consistent
> receive loop, but the inherent "nestedness" is still a mess. Should
> I make a process for each substate machine (which would make
> communicating with other players difficult as the "active" process
> is changing) or should I make nested receive loops that handle the
> substate machines?

This sort of thing is a bit difficult to do well in gen_fsm, as you
point out. One one hand, it provides built-in support for the OTP
system messages, which is good, but on the other hand, it provides
no good support for nested state machines.

Whether you should break up your state machine in multiple processes
is difficult to answer in general. Sometimes, it's a good idea, but
other times it makes things more complex. You have to go through the
different models in your mind (or on paper) and try to get a feeling
for it.

Reasonably simple sub states are nicely done with nested receives.
The gen_fsm model has a problem if you may want to handle system
messages (suspend, resume, change_code, get_status) in sub states -
gen_fsm only does that on the top level. If this is a real problem,
you can either use multiple gen_fsms (which may buy you other
problems, like synchronization bugs), or you might try out plain_fsm,
on jungerl. It tries to help you out with system messages without
forcing you to leave the textbook Erlang fsm programming model.

Discussions about plain_fsm on erlang-questions include:

http://www.erlang.org/ml-archive/erlang-questions/200402/msg00043.html

http://www.erlang.org/ml-archive/erlang-questions/200407/msg00032.html

/Uffe
-- 
Ulf Wiger