FSM advantages?

[Vance Shipley]

Eduardo,

You should also note that you can set a timeout as the FSM enters each
state.  Your callback function for init may return:

	{ok, idle, #s{}, 4000}

In which case it will enter state "idle" and if no event is received
in four seconds the event "timeout" will be received. 

idle(seize, State) ->
	...
	{next_state, seized, State, 1000}.
idle(timeout, State) ->
	...
	{next_state, idle, State, 4000}.

Each state handler, as well as handle_event/3, handle_sync_event/4 and
handle_info/3, may include a timeout in their return.

In addition to this method you can of course use timers explicitly:

idle(seize, State) ->
        ...     
	{ok, TimerReference} = timer:apply_after(1000,
			gen_fsm, send_event, [self(), seize_timer]),
	NewState#s{seize_ref = TimerReference};
        {next_state, seized, NewState}.


seized(seize_timer, State) ->
	...
seized(Other, State) ->
	timer:cancel(State#s.seize_ref),
	...


On Thu, Jan 23, 2003 at 03:18:01PM +0100, Eduardo Figoli wrote:
}  
}  Thank you I've found the  function
}  sync_send_event(FsmRef, Event, Timeout) -> Reply
}  which does exactly what I need.
}  
}  I just only need to know what's the reply term when the Timeout ocurr?
}  
}  
}  Regards,
}  Eduardo Figoli
}  INSwitch Solutions

This doesn't seem to be documented does it?  I don't know the answer as 
I've never found a reason to program synchronously in Erlang.  Try it and
see.  I suspect the answer is the atom timeout.

	-Vance