Erlang：使用gen_server：cast/2和标准消息传递之间的区别

Question

我正在通过一个问题工作，并注意到一些代码，以前的程序员使用PID的标准约定传递消息！信息。我一直在使用gen_server：cast/2。我想知道是否有人能够向我解释在两者之间进行选择时的关键区别和考虑事项？

Answer 1

有一些细微差别：

• 显然，gen_server处理中handle_cast铸件和 “正常” 的消息在handle_info。
• 演员永远不会失败;它总是返回ok。如果发送消息给当前未被进程注册的原子，则发送带有!的消息将失败，并返回badarg。 （即使进程已经停止，向pid发送消息也不会导致错误。）
• 如果gen_server正在当前未连接到本地节点的远程节点上运行，那么gen_server:cast会产生一个后台进程建立连接并发送消息，并立即返回，而!仅在连接建立时返回。 （请参阅gen_server:do_send的编码。）

至于什么时候选择其中之一，主要是品味问题。我想说如果消息可以被认为是gen_server的异步API函数，那么它应该使用cast，和在gen_server回调模块中具有特定的API函数。也就是说，而不是调用gen_server:cast直接，就像这样：

gen_server:cast(foo_proc, {some_message, 42}) 

进行函数调用：

foo_proc:some_message(42) 

和实施类似上面直接铸造该功能。它将gen_server的特定协议封装在自己的模块中。

在我看来，“简单”消息将用于事件，而不是API调用。一个例子是监视器消息，{'DOWN', Ref, process, Id, Reason}，以及可能在系统中发生的类似事件。

Answer 2

除了legoscia发布，我会说跟踪消息比追踪专用函数API更容易。特别是在产品环境中。