erlang OTP gen_fsm 图解分析
原文链接：
http://www.hoterran.info/otp-gen_fsm-sourcecode
gen_fsm和gen_server非常的类似, 在gen进程递归调用loop函数的过程中，除有StateData还额外有一个StateName的atom, 它决定了下次执行的函数. 另外一个不同之处是, gen_server程序是由调用进程向gen进程发送消息, 一种cs模式的调用关系，而gen_fsm程序中这个发送消息的通常都是gen进程本身.
-
init
初始化过程和gen_server很类似, 区别是init返回必须获得一个当前状态StateName, 这样才能继续接下来的事件处理.
如果在Mod:init返回的是{ok, State, Timeout}
{ok, State, Timeout} ->
proc_lib:init_ack(Starter, {ok, self()}),
loop(Parent, Name, State, Mod, Timeout, Debug);
则在loop函数的阻塞是有超时的，不会永久阻塞等待消息。
loop(Parent, Name, StateName, StateData, Mod, Time, Debug) ->
Msg = receive
Input ->
Input
after Time ->
{'$gen_event', timeout}
end,
decode_msg(Msg,Parent, Name, StateName, StateData, Mod, Time, Debug, false).
即便超时时间内gen进程未收到任何消息, 依然会触发StateName函数的执行, 其中Event为timeout.
dispatch({'$gen_event', Event}, Mod, StateName, StateData) ->
Mod:StateName(Event, StateData);
对于gen_server也一样可以设置为接收到消息的超时, 而他触发的函数是hanle_info, 其中Info也为timeout.
dispatch(Info, Mod, State) -> Mod:handle_info(Info, State).
-
send_event
异步事件和gen_server:cast类似并不等待gen进程的回馈, gen进程接受到异步事件和,根据当前状态StateName和异步事件Event模式匹配找到需要执行的StateName函数.
- sync_send_event
同步事件类似与gen_server:call,调用进程发送事件之后会等待gen进程的消息回馈(wait_resp_mon). 而gen进程同样根据当前的状态和同步事件决定需要执行的函数.
和call一样sync类的消息可以选择是否需要回馈信息, 如果不回馈信息则wait_resp_mon会超时退出.
包括下面sync_send_all_state_event的函数都可以调用sync_send_event/3来设置超时参数来控制在wait_resp_mon函数处阻塞的时间.
-
send_all_state_event
以上两个事件处理函数需要根据当前状态和决定函数名, 而全状态事件仅仅根据事件来决定要执行的函数, 无论当前处于哪种状态，在统一的函数handle_event里执行.
-
sync_send_all_state_event
同上,只是调用需要等到gen进程的消息回馈, 统一在handle_sync_event里处理.
-
info
和gen_server一样,不同之处多返回一个StateName.
-
terminate
和gen_server一样.