Как визуально описать gen_server?

У меня нет точного рисунка, чтобы объяснить это, но у меня есть эта глава и после того, как показано, как построить gen_server, исходя из лежащих в его основе принципов абстракции.

Чтобы помочь с отдельными компонентами:

реализация поведения

Само поведение немного похоже на то, что показано в главе, на которую я ссылался ранее. Это модуль с множеством функций, выполняющих все стандартные функции за вас: получение сообщений, определение функций и скрытых протоколов для связи и т. Д. Расширенный материал OTP содержит особые виды сообщений, используемых для обновления программного обеспечения, а также специальный код для параметров отслеживания.

контейнер поведения

Я не уверен, что это должно быть. Может просто модуль с названием поведения?

интерфейс поведения

В том же модуле, в котором реализована ваша реализация поведения, вы должны определить функцию behaviour_info/1. Эта функция сообщит компилятору Erlang, что некоторые обратные вызовы ожидаются от любого модуля, в котором есть -behaviour(SomeModuleName). SomeModuleName эквивалентен файлу SomeModuleName.erl (и .beam), который содержит реализацию и функцию behavior_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) и один для пользователя ( запускаем сервер, отправляем некоторую информацию, запрашиваем информацию обратно).

Я мог бы попытаться описать это так

---------------------------------------------------------------------
| 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 / интерфейс модуля обратного вызова, чтобы связаться с серверным процессом и оказать на него влияние.

Вы должны рассматривать поведение как своего рода очень общий сегмент кода, который иногда отказывается от своего потока выполнения (для более точных частей, таких как получение и отправка сообщений) конкретному коду (как реагировать на эти сообщения).

Надеюсь, это поможет.