Візьми номер Deluxe

GenServer

GenServer (узагальнений сервер) - це поведінка, яка абстрагує типові взаємодії клієнт-сервер між процесами Elixir.

Пригадаймо цикл отримання повідомлень, про який ми дізналися, коли вивчали процеси? Поведінка GenServer надає абстракції для реалізації таких циклів і для обміну повідомленнями з процесом, який виконує такий цикл. Вона спрощує збереження стану та виконання асинхронного коду.

Поведінка GenServer визначає один обовʼязковий колбек, init/1, і кілька цікавих необовʼязкових колбеків: handle_call/3, handle_cast/2 та handle_info/3. Клієнти, які використовують GenServer, не повинні викликати ці колбеки напряму. Натомість модуль GenServer надає функції, які клієнти можуть використовувати для звʼязку з процесом GenServer.

Часто один модуль визначає і клієнтський API, тобто набір функцій, які інші частини застосунку Elixir можуть викликати для звʼязку з цим процесом GenServer, і реалізації серверних колбеків, які містять логіку цього GenServer.

Розгляньмо спочатку простий приклад GenServer, а потім зʼясуймо, що означає кожен колбек.

Приклад

Це приклад сервера, який може відповідати на повторювані розпитування набридливих пасажирів під час довгої поїздки, а точніше на запитання: «are we there yet?». Він рахує, скільки разів це запитання вже поставили, і повертає дедалі роздратованіші відповіді.

defmodule AnnoyingPassengerAutoresponder do
  use GenServer
  # Client API

  def start_link(init_arg) do
    GenServer.start_link(__MODULE__, init_arg)
  end

  def are_we_there_yet?(pid) do
    GenServer.call(pid, :are_we_there_yet?)
  end

  # Server callbacks

  @impl GenServer
  def init(_init_arg) do
    # the initial count of questions asked is always 0
    state = 0
    {:ok, state}
  end

  @impl GenServer
  def handle_call(:are_we_there_yet?, _from, state) do
    reply =
      cond do
        state <= 3 -> "No."
        state <= 10 -> "I told you #{state} times already. No."
        true -> "..."
      end

    # increase the count of questions asked
    new_state = state + 1
    # reply to the caller
    {:reply, reply, new_state}
  end
end

Колбеки

init/1

Сервер можна запустити, викликавши GenServer.start/3 або GenServer.start_link/3. Про різницю між цими функціями ми дізналися в концепції звʼязків.

Ці дві функції:

• приймають модуль, який реалізує поведінку GenServer, як перший аргумент;
• приймають будь-що як другий аргумент, який називається init_arg. Як видно з назви, цей аргумент передається в колбек init/1;
• приймають необовʼязковий третій аргумент із розширеними опціями запуску процесу, які ми зараз не розглядатимемо.

Запуск сервера викликом GenServer.start/3 або GenServer.start_link/3 викликає колбек init/1 у блокуючий спосіб. Повернене значення init/1 визначає, чи сервер зможе успішно запуститися.

Колбек init/1 зазвичай повертає одне з таких значень:

• {:ok, state}. Сервер почне свій цикл отримання повідомлень, використовуючи state як початковий стан. state може бути будь-якого типу.
• {:stop, reason}. reason може бути будь-якого типу. Сервер не почне свій цикл отримання повідомлень. Процес завершиться із зазначеної причини.

Є також складніші можливості, які ми зараз не розглядатимемо.

Якщо цикл отримання повідомлень сервера запускається, функції GenServer.start/3 і GenServer.start_link/3 повертають кортеж {:ok, pid}. Інакше вони повертають {:error, reason}

handle_call/3

Повідомлення, яке потребує відповіді, можна надіслати процесу сервера за допомогою GenServer.call/2. Ця функція приймає pid запущеного процесу сервера як перший аргумент і повідомлення як другий аргумент. Повідомлення може бути будь-якого типу.

Колбек handle_call/3 відповідає за обробку синхронних повідомлень і відповіді на них. Він приймає три аргументи:

1. message - значення, передане другим аргументом у GenServer.call/2.
2. from - pid процесу, який викликає GenServer.call/2. Найчастіше цей аргумент можна ігнорувати.
3. state - поточний стан сервера. Пригадаймо, що його початкове значення задано в колбеку init/1.

Колбек handle_call/3 зазвичай повертає кортеж із 3 елементів {:reply, reply, state}. Це означає, що другий елемент кортежу, reply, який може бути будь-якого типу, буде надіслано назад тому, хто викликав. Третій елемент кортежу, state, - це новий стан сервера після обробки цього повідомлення.

Є також складніші можливості, які ми зараз не розглядатимемо.

handle_cast/2

Повідомлення, яке не потребує відповіді, можна надіслати процесу сервера за допомогою GenServer.cast/2. Його аргументи ідентичні аргументам GenServer.call/2.

Колбек handle_cast/2 відповідає за обробку таких повідомлень. Він приймає два аргументи, message і state, які є тими самими аргументами, що й у колбеку handle_call/3 (крім from).

Колбек handle_cast/2 зазвичай повертає кортеж із 2 елементів {:noreply, state}.

Є також складніші можливості, які ми зараз не розглядатимемо.

Використовувати call чи cast?

Майже завжди варто використовувати call, навіть якщо клієнтському коду не потрібна відповідь від сервера.

Використання call чекає на відповідь, що слугує механізмом зворотного тиску (щоб клієнти не надсилали забагато повідомлень одночасно). Отримання відповіді від сервера - це також єдиний спосіб переконатися, що сервер отримав і обробив повідомлення клієнта.

handle_info/2

Повідомлення також можуть опинятися в поштовій скриньці сервера не лише через виклик GenServer.call/2 чи GenServer.cast/2, а й, наприклад, через виклик звичайної функції send/2.

Щоб обробляти такі повідомлення, використовуймо колбек handle_info/2. Цей колбек працює точно так само, як handle_cast/2.

Поведінка GenServer надає універсальну реалізацію handle_info/2, яка записує в журнал помилки про неочікувані повідомлення. Якщо ми перевизначимо цю типову реалізацію, варто завжди додавати власну реалізацію, яка перехоплює все. Якщо ми забудемо, сервер аварійно завершиться, коли отримає неочікуване повідомлення.

Тайм-аути

Повернене значення кожного з чотирьох колбеків, описаних вище, можна доповнити ще одним елементом кортежу - тайм-аутом. Наприклад, замість повернення {:ok, state} з init/1 повернімо {:ok, state, timeout}.

Тайм-аут можна використовувати, щоб виявити відсутність повідомлень у поштовій скриньці протягом певного періоду. Якщо сервер повертає тайм-аут з одного зі своїх колбеків і вказана кількість мілісекунд минає без надходження повідомлень, викликається handle_info/2 з :timeout як першим аргументом.