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

Question

我正在解决一个问题，并注意到以前的程序员使用 PID 的标准约定传递消息的一些代码！信息。我一直在使用 gen_server:cast/2。我想知道是否有人可以向我解释在两者之间进行选择时的关键差异和考虑因素？

score 19 · Accepted Answer

有一些小的区别：

显然， gen_server 处理强制转换handle_cast和handle_info.
一个演员永远不会失败；它总是返回ok。如果您正在向当前未由进程注册的原子发送消息，则发送消息!失败。badarg（向 pid 发送消息永远不会导致错误，即使进程已死。）
如果 gen_server 运行在当前未连接到本地节点的远程节点上，gen_server:cast则将产生一个后台进程建立连接并发送消息，并立即返回，而!仅在建立连接后返回。（参见代码gen_server:do_send。）

至于何时选择其中一个，这主要是一个品味问题。我想说，如果可以将消息视为 gen_server 的异步 API 函数，那么它应该使用强制转换，并在 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}以及可能在您的系统中发生的类似事件。

score 6 · Accepted Answer

除了 legoscia 帖子之外，我想说跟踪专用函数 API 比跟踪消息更容易。特别是在生产环境中。

2 回答 2