
<html><P>For huge FSMs, we have had to deal with the trade-off of speed vs beauty vs complexity (In no particular order, as beauty should come first): </P>

<P>* We either generate the code feeding all the states, events and transitions to it.<BR>* Use a gen_server, with a state table with key {State, Event} mapping to a function which returns the next state. <BR></P>

<P>Hope it helps,</P>

<P>Francesco<BR>--<BR>http://www.erlang-consulting.com</P>

<P><BR>>-----Original Message-----<BR>>From: Richard Cameron [mailto:camster@citeulike.org]<BR>>Sent: Monday, March 20, 2006 02:31 PM<BR>>To: 'Serge Aleynikov'<BR>>Cc: 'Erlang Questions'<BR>>Subject: Re: large gen_fsms<BR>><BR>><BR>>On 20 Mar 2006, at 13:43, Serge Aleynikov wrote:<BR>><BR>>> I wonder if someone could share their experience at dealing with <BR>>> large FSMs. We are in the midst of implementing an FSM which <BR>>> logically can be broken down in two groups of states. It would be <BR>>> good to be able to split these states among two separate modules, <BR>>> but gen_fsm doesn't allow to do this easily.<BR>><BR>>I always seem end up writing large FSMs as special processes (<http:// <BR>>erlang.se/doc/doc-5.4.12/doc/design_principles/spec_proc.html>) and <BR>>simply doing things the old fashioned pure Erlang way:<BR>><BR>>state1() -><BR>> receive<BR>> go_to_state_2 -> state2();<BR>> _ -> state1()<BR>> end.<BR>><BR>>state2() -><BR>> receive<BR>> go_to_state_1 -> state1();<BR>> go_to_state_3 -> state2()<BR>> end.<BR>><BR>>...<BR>><BR>>Something like that would let you split the states over multiple <BR>>modules (assuming you can keep a mental image of the maze of cross- <BR>>module calls in your head).<BR>><BR>>The problem always find I have with gen_fsm is that events need to be <BR>>dealt with immediately. You've got the option to either pattern match <BR>>with a "don't care" variable to simply ignore an event if it occurs <BR>>when you don't want it, or you can have the FSM abnormally. What you <BR>>can't do is queue the event up to be dealt with when the FSM moves <BR>>into a more appropriate state.<BR>><BR>>I generally find that I want precisely this behaviour in at least one <BR>>of my states (and this becomes more likely the bigger the FSM is). As <BR>>Erlang's syntax is almost ideal of writing FSMs anyway, I just don't <BR>>find gen_fsm adding much (other than taking care of OTP system <BR>>messages automatically.).<BR>><BR>>Richard.<BR>></P></html>