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

时间:2014-04-09 16:22:52

标签: asynchronous erlang gen-server

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

2 个答案:

答案 0 :(得分:15)

存在一些细微差别:

  • 显然,gen_server处理handle_cast中的handle_info和“普通”消息中的强制转换。
  • 演员从未失败;它总是返回ok。如果要向当前未由进程注册的原子发送消息,则发送带有!的消息将失败并显示badarg。 (即使进程已经死亡,向pid发送消息也不会导致错误。)
  • 如果gen_server正在当前未连接到本地节点的远程节点上运行,则gen_server:cast将生成后台进程以建立连接并发送消息,并立即返回{{1只有在建立连接后才会返回。 (请参阅!的代码。)

至于何时选择其中一种,主要是品味问题。我要说如果消息可以被认为是gen_server的异步API函数,那么它应该使用强制转换,在gen_server回调模块中有一个特定的API函数。也就是说,不要直接调用gen_server:do_send,而是这样:

gen_server:cast

进行函数调用:

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

并像上面的直接演员那样实现该功能。这将gen_server的特定协议封装在其自己的模块中。

在我看来,“普通”消息将用于事件,而不是API调用。一个示例是监视器消息,foo_proc:some_message(42) 以及系统中可能发生的类似事件。

答案 1 :(得分:5)

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