[erlang-questions] FSM: How to wait the end of handle_info ?

Robert Virding <>
Wed May 9 16:12:09 CEST 2012


You can use gen_fsm:reply/2 to explicitly send the reply back to the caller of gen_fsm:sync_send_event/2. But note then the State/3 functions must not return a reply value which the behaviour automatically send back to the client, it must just return {next_state,...}. But then the gen_fsm:sync_send_event call will wait! 

Robert 

----- Original Message -----

> Hello everybody,

> I have two files, main.erl which control a finite state machine (FSM)
> with a gen_fsm behavior.
> The FSM is also able to received incoming data from a socket for
> certain state (using the handle_info method).

> The question is how the main program can wait and know the next state
> after handle_info callback is done by the gen_fsm....
> because, according to the rawdata received the system move to another
> state and main.erl must know this new state to send specifics
> events....

> Maybe more easy to understand with a small illustration

> main.erl
> {ok, FSMPid} = myfsm:start_link(...),
> ok = gen_fsm:sync_send_event(FSMPid, event1)
> % => will move the FSM to state_5 where we are waiting socket
> incoming data
> % these data will be handle by "handle_info({tcp, _Socket, RawData},
> state_5, StateData)"
> % depending on the received socket rawdata, we will change the state
> of the FSM

> => How can I wait handle_info has finished ?
> => How can I get the state ?
> (for this last question, I think I can just send a
> send_all_state(FSMPid, current_state) for example and return the
> StateName

> program will continue like this:
> case StateName of
> state_13 -> send another event
> ....

> thanks for help,

> Arnaud

> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120509/bb0db66c/attachment.html>


More information about the erlang-questions mailing list