可以在gen_fsm状态回调中处理任何收到的消息吗？ [英] Can I handle any received message in gen_fsm state callbacks?

问题描述

我注意到发送到gen_fsm进程的pid的消息在状态回调中与事件匹配。这是只是偶然的，还是我可以依靠这个功能？

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?

通常我会期待发送到gen_fsm的一般消息显示在handle_info / 3回调中，并认为我会必须使用gen_fsm：send_event重新发送它。

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.

gen_fsm是否尝试将消息首先匹配到状态回调，然后与handle_info / 3回调一起使用？或者只有当它不符合状态回调条款？

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.

所以基本上这个问题也可以说如下：如何正确处理收到的消息作为gen_fsm状态函数中的事件？

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.

我不太清楚，如果这将改善当前提到的gen_fsm必须适应的框架：不同的协议栈，其中每个层调用一个connect（）函数附加（有时开始）下层。数据包被发送到较低层，呼叫功能（发送），并通过接收发送消息。很像gen_tcp。

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.

通过查看gen_fsm的代码，我已经知道一般消息只传递给handle_info，所以只有问题直接从handle_info调用状态函数/ 3回调或使用gen_fsm重新发送：send_event。

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.

推荐答案

一般消息由handle_info回调处理，除非你有这样的东西你的代码：

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）

handle_info(Info, StateName, StateData) -> ?MODULE:StateName(Info, StateData).

其中避免重新发送，但我不建议不要再重新发送。

Which avoids resending, but I do not recommend neither that, nor resending.

通过API调用专门提供事件，封装了send_event / sync_send_event / send_all_state_event / sync_send_all_state_event使协议显式。哪个是正确的事情，因为它更容易理解，维护和记录edoc。

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.

这篇关于可以在gen_fsm状态回调中处理任何收到的消息吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！