large gen_fsms

[Francesco Cesarini (Erlang Consulting)]

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): 
* We either generate the code feeding all the states, events and transitions to it.
* Use a gen_server, with a state table with key {State, Event} mapping to a function which returns the next state. 

Hope it helps,
Francesco
--
http://www.erlang-consulting.com

>-----Original Message-----
>From: Richard Cameron [mailto:camster@REDACTED]
>Sent: Monday, March 20, 2006 02:31 PM
>To: 'Serge Aleynikov'
>Cc: 'Erlang Questions'
>Subject: Re: large gen_fsms
>
>
>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() ->
> receive
> go_to_state_2 -> state2();
> _ -> state1()
> end.
>
>state2() ->
> receive
> go_to_state_1 -> state1();
> go_to_state_3 -> state2()
> end.
>
>...
>
>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.).
>
>Richard.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060320/8fc0855f/attachment.htm>