我可以在 gen_fsm 状态回调中处理任何收到的消息吗？
我注意到发送到 gen_fsm 进程 pid 的消息在状态回调中作为事件进行匹配。这只是偶然还是我可以依赖这个功能？
通常，我希望发送到 gen_fsm 的一般消息显示在 handle_info/3 回调中，并且认为我必须使用 gen_fsm:send_event 重新发送它。
gen_fsm 是否尝试首先将消息与状态回调匹配，然后始终与handle_info/3 回调匹配？或者仅当它与状态回调子句不匹配时？
但是，当我尝试时，我的消息似乎根据调试输出被处理了两次。
所以基本上这个问题也可以表述为：如何正确处理接收到的消息作为 gen_fsm 状态函数中的事件？
说明：对于此问题，应考虑考虑通过获取传递的消息而发生的某些事件。
我知道，在许多情况下，仅使用 fsm 中的函数调用来使协议可见会更干净。
我不太确定这是否会改进当前框架，其中提到的 gen_fsm 必须适应：不同的协议栈，其中每层调用 connect() 函数来附加（有时启动）较低层。数据包通过调用函数（发送）发送到较低层，并通过接收消息来接收。很像 gen_tcp。
通过查看 gen_fsm 的代码，我已经发现一般消息仅传递给handle_info，因此剩下的问题是直接从handle_info/3回调调用状态函数还是使用gen_fsm:send_event重新发送。
I noticed that messages sent to the pid of a gen_fsm process are matched in the state callbacks as events. Is this just accidental or can I rely on this feature?
Normally I would expect general messages sent to a gen_fsm to show up in the handle_info/3 callback and thought I would have to re-send it using gen_fsm:send_event.
Does gen_fsm try to match the message first to the state callback and then allways with the handle_info/3 callback? Or only if it doesn't match a state callback clause?
However when I try it my message seems to be handled twice according to debug output.
So basically the question can also be stated like: how to correctly handle received messages as events in gen_fsm state functions?
Clarification: that some of the events are occurring by getting messages passed should be considered given for this question.
I'm aware that in many cases its cleaner to make the protocol visible by using function calls into the fsm only.
I'm not so sure if this would improve the current framework where the mentioned gen_fsm has to fit in: Diverse protocol stacks where each layer calls a connect() function to attach (and sometimes start) the lower layer. Packets are sent to lower layers ba calling a function (send) and received by receiveing a message. Much like gen_tcp.
By looking at the code for gen_fsm I already figured out that general messages are only passed to handle_info, so only the question remains wether to call the state function directly from the handle_info/3 callback or resent using gen_fsm:send_event.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般消息由handle_info回调处理，除非你的代码中有这样的东西：
handle_info(Info, StateName, StateData) ->
？模块：状态名称（信息，状态数据）。
这可以避免重新发送，但我既不建议这样做，也不建议重新发送。
仅通过封装 send_event/sync_send_event/send_all_state_event/sync_send_all_state_event 的 API 调用来传递事件，使协议变得明确。这是一件正确的事情，因为使用 edoc 更容易理解、维护和记录。
General messages are handled by handle_info callback, unless you have something like this in your code:
handle_info(Info, StateName, StateData) ->
?MODULE:StateName(Info, StateData).
Which avoids resending, but I do not recommend neither that, nor resending.
Delivering events exclusively by means of API calls encapsulating send_event/sync_send_event/send_all_state_event/sync_send_all_state_event makes protocol explicit. Which is a right thing, as it is easier to understand, maintain and document with edoc.