如何直观地描述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-introduction-to-otp-behaviors-part-i-genserver ;
• 'ErlyBank'在http://spawnlink.com/articles/an-introduction-to-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://cryptoanarchy.org/wiki/Worker_patterns(模型).但是,它没有显示模块,功能和过程之间的交互.

Answer 1

我没有一个精确的图来解释它,但我有这一章和后面的一个展示如何构建gen​​_server从它背后的抽象原则开始.

帮助处理各个组件:

行为实施

行为本身有点像我之前链接过的章节.它是一个包含许多函数的模块,为您完成所有通用工作:接收消息,定义函数和隐藏协议进行通信等.高级OTP包含用于进行软件升级的特殊消息类型以及用于跟踪选项的特殊代码.

行为容器

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

行为界面

在行为实现的同一模块中,您必须定义一个behaviour_info/1函数.该函数将让Erlang编译器知道某些回调是从其中的任何模块中获得-behaviour(SomeModuleName)的.在SomeModuleName相当于SomeModuleName.erl(并.beam包含实现和behaviour_info功能)的文件.

回调模块

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

回调函数

非通用的所有东西都可以以形式委托给回调模块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),以及用户的接口(start服务器,发送一些信息,回复一些信息).

我可以尝试用那种方式描述它

---------------------------------------------------------------------
| 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 /接口来联系服务器进程并对其产生影响.

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

希望这会有所帮助.