Mon Mar 20 20:59:08 CET 2006
On 3/20/06, Richard Cameron <> wrote:
> On 20 Mar 2006, at 13:43, Serge Aleynikov wrote:
> > I wonder if someone could share their experience at dealing with
> > large FSMs. We are in the midst of implementing an FSM which
> > logically can be broken down in two groups of states. It would be
> > good to be able to split these states among two separate modules,
> > but gen_fsm doesn't allow to do this easily.
> I always seem end up writing large FSMs as special processes (<http://
> erlang.se/doc/doc-5.4.12/doc/design_principles/spec_proc.html>) and
> simply doing things the old fashioned pure Erlang way:
> state1() ->
> go_to_state_2 -> state2();
> _ -> state1()
> state2() ->
> go_to_state_1 -> state1();
> go_to_state_3 -> state2()
> Something like that would let you split the states over multiple
> modules (assuming you can keep a mental image of the maze of cross-
> module calls in your head).
> The problem always find I have with gen_fsm is that events need to be
> dealt with immediately. You've got the option to either pattern match
> with a "don't care" variable to simply ignore an event if it occurs
> when you don't want it, or you can have the FSM abnormally. What you
> can't do is queue the event up to be dealt with when the FSM moves
> into a more appropriate state.
> I generally find that I want precisely this behaviour in at least one
> of my states (and this becomes more likely the bigger the FSM is). As
> Erlang's syntax is almost ideal of writing FSMs anyway, I just don't
> find gen_fsm adding much (other than taking care of OTP system
> messages automatically.).
Wouldn't this cause the stack to bloat indefinitely? Or does tail-calling
eliminate this in Erlang?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions