How to describe gen_server visually?

Question

Disclaimer: The author is new to OTP with a basic knowledge of Erlang syntax, processes, and messages.

I am trying to understand the concept of behavior in Erlang, but many spring questions in my head do not allow me to understand the whole principle of such behavior as gen_server.

Well, the official documentation for gen_server shows a good diagram of the server and the three clients related to Query and Reply arrows: http://www.erlang.org/doc/design_principles/gen_server_concepts.html

But every time I try to understand the concept further, I get stuck.

There are many concepts that I cannot build in one larger concept in my head:

• implementation of behavior;
• container behavior;
• behavior interface;
• callback module;
• callback functions;
• API functions

I use the following resources:

• Erlang / OTP in the action book;
• Introduction to OTP Behavior Presentation, http://www.slideshare.net/gamlidek/ceug-introduction-to-otp-behaviors-part-i-genserver ;
• 'ErlyBank' at http://spawnlink.com/articles/an-introduction-to-gen_server-erlybank/index.html .

I'm still in the state of "we call one function in one module, this function calls another function, this function creates a process ... stuck"

Is it possible to describe the concept of gen_server in a diagram? How is the visual flow of interaction between clients and server? (to help not so smart beginners visually understand the concept)

For example, for example: http://support.novell.com/techcenter/articles/img/dnd2003080506.gif

UPD: I tried to draw my own diagram, but I still do not understand the purpose of any connector on the diagram: http://postimage.org/image/qe215ric/full/

UPD2: This is similar to what I would like to see: http://cryptoanarchy.org/wiki/Worker_patterns (The Model). However, it does not show the interaction between modules, functions, and processes.

Answer 1

I do not have an exact drawing to explain this, but I have in this chapter , and after I have shown how to create gen_server, starting with the principles of abstraction that lie behind it.

To help with individual components:

implementation of behavior

The behavior itself is a bit like the one shown in the previous chapter I. This is a module with many functions that perform all the common things for you: receiving messages, defining functions and hidden protocols for communication, etc. The OTP extended material contains special types of messages used to update software, as well as special code for trace parameters.

container behavior

I'm not sure what it should be. Maybe just a module named behavior?

behavior interface

In the same module, your implementation of the behavior, you must define the function behaviour_info/1 . This function will let the Erlang compiler know that some callbacks are expected from any module with -behaviour(SomeModuleName) . SomeModuleName equivalent to the file SomeModuleName.erl (and .beam ), which contains the implementation and function behaviour_info.

callback module

A module that will contain all the specific code, processing all user materials.

callback functions

Everything that is not shared must be delegated to the callback module in the form of YourModule:SomeCall(Args) . This is provided by your module, which has the line -behaviour(gen_server). .

API Functions

The callback module has two interfaces if you want: one for the behavior of gen_server (init / 0, handle_call / 3, handle_info / 2, handle_cast / 2, terminate / 2, code_change / 3) and one for the user (start the server, send some information, ask for some information back).

I could try to describe it that way

 --------------------------------------------------------------------- | 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 <--------|---------------------:--------` | : 

All common parts are to the right of the server process, as part of the behavior, and all defined parts are to the left (callback). The client uses the callback module API to contact the server process and have an effect on it.

You should see behavior as a kind of very general segment of code that sometimes refuses the flow of execution (to get more precise details, such as receiving and sending messages) to a specific code (how to respond to these messages).

Hope this helps.