如何形象地描述gen_server？

Question

免责声明：作者是 OTP 的新手，对 Erlang 的语法、过程和消息有一些基本了解。

我试图掌握 Erlang 中的行为概念，但我的脑海中浮现出很多问题，阻止了我的理解。我从理解像 gen_server 这样的行为的整个原理开始。

好的，gen_server 的官方文档显示了一个服务器和三个通过查询和回复箭头连接的客户端的漂亮图表： http://www.erlang.org/doc/design_principles/gen_server_concepts.html

但每次我试图进一步理解这个概念时，我都会陷入困境。

有很多概念我无法在脑海中构建成一个更大的概念：

• 行为实现；
• 行为容器；
• 行为界面；
• 回调模块；
• 回调函数；
• API 函数。

我使用以下资源：

• Erlang/OTP in Action 书籍；
• OTP 行为演示介绍，http://www .slideshare.net/gamlidek/ceug-otp-behaviors-part-i-genserver;
• “ErlyBank”位于 http://spawnlink.com/articles/an -gen_server-erlybank/index.html 简介。

我仍然处于“我们在一个模块中调用一个函数，这个函数调用另一个函数，该函数创建一个进程......卡住”的状态

有什么方法可以在图表中描述 gen_server 的概念吗？如何直观地展示客户端和服务器之间的交互流程？（帮助不太聪明的新手直观地理解概念）

例如：http://support.novell.com/techcenter/articles/img/dnd2003080506.gif

UPD：我尝试绘制自己的图表，但我仍然不明白图中任何连接器的用途： http://postimage.org/image/qe215ric/full/

UPD2：这与我希望看到的类似：http://cryptoaarchy.org/wiki/Worker_patterns（模型）。然而，它没有显示模块、功能和进程之间的交互。

Answer 1

我没有精确的绘图来解释它，但我有这一章 以及展示如何从其背后的抽象原则开始构建 gen_server 之后的一个。

帮助各个组件：

行为实现

行为本身有点像我之前链接的章节中显示的内容。它是一个具有一堆功能的模块，可以为您完成所有通用的工作：接收消息、定义功能和隐藏的通信协议等。高级 OTP 内容包含用于进行软件升级的特殊类型的消息以及用于跟踪选项的特殊代码。

行为容器

我不确定这应该是什么。也许只是带有行为名称的模块？

行为接口

在行为实现所在的同一模块中，您必须定义一个 behaviour_info/1 函数。该函数会让 Erlang 编译器知道任何包含 -behaviour(SomeModuleName) 的模块都需要一些回调。 SomeModuleName 相当于包含实现和 Behaviour_info 函数的 SomeModuleName.erl （和 .beam）文件。

回调模块

该模块将包含所有特定代码，处理所有自定义内容。

回调函数

所有不通用的内容都以 YourModule:SomeCall(Args) 的形式委托给回调模块。这些由您的模块提供，该模块中包含 -behaviour(gen_server). 行。

API 函数

如果需要，回调模块有两个接口： 用于 gen_server 行为的接口（init/0、handle_call/3、handle_info/2、handle_cast/2、terminate/2、code_change/3 ），以及用户的一个（启动服务器，发送一些信息，要求返回一些信息）。

我可以尝试以这种方式描述它，

---------------------------------------------------------------------
| some process          |                server process             |
------------------------+--------------------------------------------
   [client]             |      [callback]     :        [behaviour]
                        |                     :
 callback:start >-------|---------------------:--> starting the process
                        |                     :           V
                        |                     :           |
                        |       init()  <-----:-----------`
                        |         |           :
                        |         `-----------:------> initial state
  {ok, Pid}  <----------|---------------------:----------,/
                        |                     :
 callback:store  >------|---------------------:--> handles message
 (calls the process)    |    (formats msg)    :           V
                        |                     :           |
                        |    handle_call() <--:-----------` 
                        |         |           :
                        |          `----------:--> updates state, sends reply
                        |                     :        V
                        |                     :        |
   gets result <--------|---------------------:--------`
                        |                     :       

所有通用部分都位于服务器进程的右侧，在行为内，所有特定部分都位于左侧（回调）。客户端使用回调模块的API/接口来联系服务器进程并对其产生影响。

您必须将行为视为某种非常通用的代码段，有时会将其执行流（对于更精确的部分，例如接收和发送消息）放弃给特定代码（如何对这些消息做出反应）。

希望这有帮助。