Take-A-Number Deluxe

GenServer

GenServer (generischer Server) ist ein Behaviour, das häufige Client-Server-Interaktionen zwischen Elixir-Prozessen abstrahiert.

Erinnerst du dich an die Empfangsschleife aus dem Kapitel über Prozesse? Das GenServer-Behaviour bietet Abstraktionen, um solche Schleifen zu implementieren und um Nachrichten mit einem Prozess auszutauschen, der eine solche Schleife ausführt. Damit lässt sich der Zustand leichter verwalten und asynchroner Code leichter ausführen.

Das GenServer-Behaviour definiert einen erforderlichen Callback, init/1, und ein paar interessante optionale Callbacks: handle_call/3, handle_cast/2 und handle_info/3. Die Clients, die einen GenServer verwenden, sollen diese Callbacks nicht direkt aufrufen. Stattdessen stellt das Modul GenServer Funktionen bereit, mit denen Clients mit einem GenServer-Prozess kommunizieren können.

Häufig definiert ein einzelnes Modul sowohl eine Client-API, also eine Reihe von Funktionen, die andere Teile deiner Elixir-App aufrufen können, um mit diesem GenServer-Prozess zu kommunizieren, als auch Server-Callback-Implementierungen, die die Logik dieses GenServer enthalten.

Schauen wir uns zuerst ein einfaches Beispiel für einen GenServer an und lernen dann, was die einzelnen Callbacks bedeuten.

Beispiel

Dies ist ein Beispielserver, der auf die wiederholten Fragen nerviger Mitfahrer während einer langen Autofahrt reagieren kann, genauer gesagt auf die Frage: „Sind wir schon da?". Er zählt mit, wie oft diese Frage gestellt wurde, und gibt zunehmend genervtere Antworten zurück.

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

Callbacks

init/1

Ein Server kann gestartet werden, indem man GenServer.start/3 oder GenServer.start_link/3 aufruft. Den Unterschied zwischen diesen Funktionen haben wir im Links-Konzept kennengelernt.

Diese beiden Funktionen:

• Akzeptieren ein Modul, das das GenServer-Behaviour implementiert, als erstes Argument.
• Akzeptieren einen beliebigen Wert als zweites Argument namens init_arg. Wie der Name schon verrät, wird dieses Argument an den Callback init/1 übergeben.
• Akzeptieren ein optionales drittes Argument mit fortgeschrittenen Optionen für den Prozess, die wir jetzt nicht behandeln.

Wenn du einen Server mit GenServer.start/3 oder GenServer.start_link/3 startest, wird der Callback init/1 blockierend aufgerufen. Der Rückgabewert von init/1 entscheidet, ob der Server erfolgreich gestartet werden kann.

Der Callback init/1 gibt normalerweise einen der folgenden Werte zurück:

• {:ok, state}. Der Server startet seine Empfangsschleife und verwendet state als Anfangszustand. state kann von beliebigem Typ sein.
• {:stop, reason}. reason kann von beliebigem Typ sein. Der Server startet seine Empfangsschleife nicht. Der Prozess beendet sich mit dem angegebenen Grund.

Es gibt auch noch fortgeschrittenere Möglichkeiten, die wir jetzt nicht behandeln.

Wenn die Empfangsschleife des Servers startet, geben die Funktionen GenServer.start/3 und GenServer.start_link/3 ein {:ok, pid}-Tupel zurück. Andernfalls geben sie {:error, reason} zurück.

handle_call/3

Eine Nachricht, die eine Antwort erfordert, kann mit GenServer.call/2 an einen Serverprozess gesendet werden. Diese Funktion erwartet die pid eines laufenden Serverprozesses als erstes Argument und die Nachricht als zweites Argument. Die Nachricht kann von beliebigem Typ sein.

Der Callback handle_call/3 ist dafür zuständig, synchrone Nachrichten zu verarbeiten und zu beantworten. Er erhält drei Argumente:

1. message – der Wert, der als zweites Argument an GenServer.call/2 übergeben wurde.
2. from – die pid des Prozesses, der GenServer.call/2 aufruft. Meistens kann dieses Argument ignoriert werden.
3. state – der aktuelle Zustand des Servers. Denk daran, dass sein Anfangswert im Callback init/1 gesetzt wurde.

Der Callback handle_call/3 gibt normalerweise ein 3er-Tupel {:reply, reply, state} zurück. Das bedeutet, dass das zweite Element des Tupels, eine reply von beliebigem Typ, an den Aufrufer zurückgeschickt wird. Das dritte Element des Tupels, state, ist der neue Zustand des Servers nach der Verarbeitung dieser Nachricht.

Es gibt auch noch fortgeschrittenere Möglichkeiten, die wir jetzt nicht behandeln.

handle_cast/2

Eine Nachricht, die keine Antwort erfordert, kann mit GenServer.cast/2 an einen Serverprozess gesendet werden. Ihre Argumente sind identisch mit denen von GenServer.call/2.

Der Callback handle_cast/2 ist dafür zuständig, diese Nachrichten zu verarbeiten. Er erhält zwei Argumente, message und state, dieselben Argumente wie beim Callback handle_call/3 (bis auf from).

Der Callback handle_cast/2 gibt normalerweise ein 2er-Tupel {:noreply, state} zurück.

Es gibt auch noch fortgeschrittenere Möglichkeiten, die wir jetzt nicht behandeln.

Sollte ich call oder cast verwenden?

Verwende fast immer call, auch wenn dein Client-Code die Antwort des Servers nicht braucht.

Bei call wartest du auf die Antwort, die als Backpressure-Mechanismus dient (um zu verhindern, dass Clients zu viele Nachrichten auf einmal senden). Eine Antwort vom Server zu erhalten ist außerdem der einzige Weg, sicher zu sein, dass der Server die Nachricht des Clients empfangen und verarbeitet hat.

handle_info/2

Nachrichten können auch auf anderem Weg als über GenServer.call/2 oder GenServer.cast/2 im Postfach des Servers landen, zum Beispiel durch einen Aufruf der einfachen Funktion send/2.

Um solche Nachrichten zu verarbeiten, verwende den Callback handle_info/2. Dieser Callback funktioniert genauso wie handle_cast/2.

Das GenServer-Behaviour bietet eine Catch-all-Implementierung von handle_info/2, die Fehler über unerwartete Nachrichten protokolliert. Wenn du diese Standardimplementierung überschreibst, achte darauf, immer eine eigene Catch-all-Implementierung anzugeben. Wenn du das vergisst, stürzt der Server ab, sobald er eine unerwartete Nachricht erhält.

Timeouts

Der Rückgabewert jedes der vier oben beschriebenen Callbacks kann um ein weiteres Tupel-Element erweitert werden, ein Timeout. Statt zum Beispiel aus init/1 {:ok, state} zurückzugeben, gibst du {:ok, state, timeout} zurück.

Mit dem Timeout kannst du feststellen, dass über einen bestimmten Zeitraum keine Nachrichten im Postfach eingehen. Wenn der Server aus einem seiner Callbacks ein Timeout zurückgibt und die angegebene Anzahl Millisekunden verstrichen ist, ohne dass eine Nachricht eintrifft, wird handle_info/2 mit :timeout als erstem Argument aufgerufen.