Big state machines

[Vance Shipley]

On Mon, Apr 18, 2005 at 12:47:33PM +0300, joel reymont wrote:
}  
}  A big thanks to all who replied. I had the insight over the weekend
}  that as Ulf said the code can be rewritten with selective receive. I
}  decided to stick with gen_fsm, though. I´ll post if I have problems.


A classical finite state machine has no state data.  It only reacts to
input events performing an action such as sending a signal and moving
to another one of a finite number of states.  The only memory it has is
it's program for the state it's in.  Once it has moved to another state
it has no knowledge of what state it was last in or anything which has 
happened previously.

The gen_fsm behaviour is an example of an extended communicating finite
state machine.  The difference being that it has state data; it remembers
things (if we took away the StateData argument to the state handlers it
would be a classical FSM).  This expands their utility but increases the
complexity.  A simple use of state data would be to keep counters so that
we could execute exceptions such as maximum retries.  On the other hand
you could take an FSM with ten states and reduce it to one by abusing the
state data.

If you can identify the natural FSMs in your problem and map them one to
one to gen_fsm processes it should be quite mangeable.  If it seems 
unmanageable you've probably overloaded it.

An advanced concept is that each of the states may itself be a state 
machine.  If you can map the main problem to a reasonably sozed state 
machine you may be able to map the details onto sub state machines.

SDL is a useful modeling tool which maps well onto Erlang however it does
extend things further to use selective receive.  SDL has a save which
says that it should leave any unmentioned events in the event queue.  I
still map SDL onto gen_fsms though and use state data to retain the saved
signals.  I've often wondered about building a new behaviour to handle
selective receive but have yet to investigate it.

	-Vance