Prends un numéro deluxe

GenServer

GenServer (serveur générique) est un comportement qui fournit une abstraction pour les interactions client-serveur courantes entre processus Elixir.

Tu te souviens de la boucle de réception, quand on a découvert les processus ? Le comportement GenServer fournit des abstractions pour implémenter de telles boucles, et pour échanger des messages avec un processus qui exécute une telle boucle. Il facilite la conservation d'un état et l'exécution de code asynchrone.

Le comportement GenServer définit un callback obligatoire, init/1, et quelques callbacks facultatifs intéressants : handle_call/3, handle_cast/2 et handle_info/3. Les clients qui utilisent un GenServer ne sont pas censés appeler ces callbacks directement. À la place, le module GenServer fournit des fonctions que les clients peuvent utiliser pour communiquer avec un processus GenServer.

Souvent, un seul module définit à la fois une API client, un ensemble de fonctions que les autres parties de ton application Elixir peuvent appeler pour communiquer avec ce processus GenServer, et des implémentations de callbacks serveur, qui contiennent la logique de ce GenServer.

Regardons d'abord un exemple simple de GenServer, puis on verra ce que chaque callback signifie.

Exemple

Voici un exemple de serveur capable de répondre aux questions répétitives de passagers pénibles pendant un long trajet en voiture, plus précisément à la question : « on est bientôt arrivés ? ». Il garde la trace du nombre de fois où cette question a été posée, et renvoie des réponses de plus en plus agacées.

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

Un serveur peut être démarré en appelant GenServer.start/3 ou GenServer.start_link/3. On a vu la différence entre ces deux fonctions dans le concept des liens.

Ces deux fonctions :

• Acceptent en premier argument un module qui implémente le comportement GenServer.
• Acceptent n'importe quoi en deuxième argument, appelé init_arg. Comme son nom le suggère, cet argument est passé au callback init/1.
• Acceptent un troisième argument facultatif contenant des options avancées pour l'exécution du processus, que l'on ne verra pas maintenant.

Démarrer un serveur en appelant GenServer.start/3 ou GenServer.start_link/3 invoque le callback init/1 de manière bloquante. La valeur de retour de init/1 détermine si le serveur peut démarrer correctement.

Le callback init/1 renvoie généralement l'une de ces valeurs :

• {:ok, state}. Le serveur démarre sa boucle de réception en utilisant state comme état initial. state peut être de n'importe quel type.
• {:stop, reason}. reason peut être de n'importe quel type. Le serveur ne démarre pas sa boucle de réception. Le processus se termine avec la raison donnée.

Il existe aussi des possibilités plus avancées que l'on ne verra pas maintenant.

Si la boucle de réception du serveur démarre, les fonctions GenServer.start/3 et GenServer.start_link/3 renvoient un tuple {:ok, pid}. Sinon, elles renvoient {:error, reason}

handle_call/3

On peut envoyer un message qui nécessite une réponse à un processus serveur avec GenServer.call/2. Cette fonction attend en premier argument le pid d'un processus serveur en cours d'exécution, et le message en deuxième argument. Le message peut être de n'importe quel type.

Le callback handle_call/3 est chargé de traiter les messages synchrones et d'y répondre. Il reçoit trois arguments :

1. message : la valeur passée en deuxième argument à GenServer.call/2.
2. from : le pid du processus qui appelle GenServer.call/2. La plupart du temps, cet argument peut être ignoré.
3. state : l'état actuel du serveur. Rappelle-toi que sa valeur initiale a été définie dans le callback init/1.

Le callback handle_call/3 renvoie généralement un tuple de 3 éléments {:reply, reply, state}. Cela signifie que le deuxième élément du tuple, un reply qui peut être de n'importe quel type, est renvoyé à l'appelant. Le troisième élément du tuple, state, est le nouvel état du serveur après le traitement de ce message.

Il existe aussi des possibilités plus avancées que l'on ne verra pas maintenant.

handle_cast/2

On peut envoyer un message qui n'attend pas de réponse à un processus serveur avec GenServer.cast/2. Ses arguments sont identiques à ceux de GenServer.call/2.

Le callback handle_cast/2 est chargé de traiter ces messages. Il reçoit deux arguments, message et state, qui sont les mêmes que dans le callback handle_call/3 (à l'exception de from).

Le callback handle_cast/2 renvoie généralement un tuple de 2 éléments {:noreply, state}.

Il existe aussi des possibilités plus avancées que l'on ne verra pas maintenant.

Faut-il utiliser call ou cast ?

Utilise presque toujours call, même si ton code client n'a pas besoin de la réponse du serveur.

Avec call, on attend la réponse, ce qui sert de mécanisme de contre-pression (pour éviter que les clients envoient trop de messages d'un coup). Recevoir une réponse du serveur est aussi le seul moyen d'être sûr que le serveur a bien reçu et traité le message du client.

handle_info/2

Des messages peuvent aussi arriver dans la boîte de réception du serveur par d'autres moyens que l'appel à GenServer.call/2 ou GenServer.cast/2, par exemple en appelant la simple fonction send/2.

Pour traiter de tels messages, utilise le callback handle_info/2. Ce callback fonctionne exactement de la même manière que handle_cast/2.

Le comportement GenServer fournit une implémentation fourre-tout de handle_info/2 qui journalise les erreurs liées aux messages inattendus. Si tu redéfinis cette implémentation par défaut, veille à toujours inclure ta propre implémentation fourre-tout. Si tu l'oublies, le serveur plantera s'il reçoit un message inattendu.

Délais d'attente

La valeur de retour de chacun des quatre callbacks décrits ci-dessus peut être complétée par un élément de tuple supplémentaire, un délai d'attente. Par exemple, au lieu de renvoyer {:ok, state} depuis init/1, renvoie {:ok, state, timeout}.

Le délai d'attente permet de détecter l'absence de messages dans la boîte aux lettres pendant une période donnée. Si le serveur renvoie un délai d'attente depuis l'un de ses callbacks, et que le nombre de millisecondes spécifié s'est écoulé sans qu'aucun message n'arrive, handle_info/2 est appelé avec :timeout comme premier argument.