Prendi un numero Deluxe

GenServer

GenServer (server generico) è un comportamento che astrae le interazioni client-server comuni tra i processi Elixir.

Ricordi il ciclo di ricezione di quando abbiamo imparato a conoscere i processi? Il comportamento GenServer fornisce astrazioni per implementare tali cicli e per scambiare messaggi con un processo che esegue un ciclo del genere. Rende più facile mantenere lo stato ed eseguire codice asincrono.

Il comportamento GenServer definisce una callback obbligatoria, init/1, e alcune interessanti callback opzionali: handle_call/3, handle_cast/2 e handle_info/3. I client che usano un GenServer non dovrebbero chiamare direttamente quelle callback. Al contrario, il modulo GenServer fornisce funzioni che i client possono usare per comunicare con un processo GenServer.

Spesso un unico modulo definisce sia un'API client, un insieme di funzioni che altre parti della tua app Elixir possono chiamare per comunicare con questo processo GenServer, sia l'implementazione delle callback del server, che contiene la logica di questo GenServer.

Diamo prima un'occhiata a un semplice esempio di GenServer, poi vediamo cosa significa ciascuna callback.

Esempio

Questo è un esempio di server in grado di rispondere alle ripetitive insistenze di passeggeri fastidiosi durante un lungo viaggio in auto, più precisamente alla domanda: «siamo già arrivati?». Tiene traccia di quante volte è stata posta questa domanda e restituisce risposte sempre più seccate.

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

Callback

init/1

Un server può essere avviato chiamando GenServer.start/3 o GenServer.start_link/3. Abbiamo imparato la differenza tra queste funzioni nel concetto di link.

Queste due funzioni:

• Accettano come primo argomento un modulo che implementa il comportamento GenServer.
• Accettano qualsiasi cosa come secondo argomento, chiamato init_arg. Come suggerisce il nome, questo argomento viene passato alla callback init/1.
• Accettano un terzo argomento opzionale con opzioni avanzate per l'esecuzione del processo, che non tratteremo ora.

Avviare un server chiamando GenServer.start/3 o GenServer.start_link/3 invoca la callback init/1 in modo bloccante. Il valore restituito da init/1 determina se il server può essere avviato con successo.

La callback init/1 di solito restituisce uno di questi valori:

• {:ok, state}. Il server avvierà il suo ciclo di ricezione usando state come stato iniziale. state può essere di qualsiasi tipo.
• {:stop, reason}. reason può essere di qualsiasi tipo. Il server non avvierà il suo ciclo di ricezione. Il processo terminerà con il motivo indicato.

Esistono anche possibilità più avanzate che non tratteremo ora.

Se il ciclo di ricezione del server parte, le funzioni GenServer.start/3 e GenServer.start_link/3 restituiscono una tupla {:ok, pid}. Altrimenti restituiscono {:error, reason}

handle_call/3

Un messaggio che richiede una risposta può essere inviato a un processo server con GenServer.call/2. Questa funzione si aspetta il pid di un processo server in esecuzione come primo argomento e il messaggio come secondo argomento. Il messaggio può essere di qualsiasi tipo.

La callback handle_call/3 si occupa di gestire e rispondere ai messaggi sincroni. Riceve tre argomenti:

1. message: il valore passato come secondo argomento a GenServer.call/2.
2. from: il pid del processo che chiama GenServer.call/2. Il più delle volte questo argomento può essere ignorato.
3. state: lo stato attuale del server. Ricorda che il suo valore iniziale è stato impostato nella callback init/1.

La callback handle_call/3 di solito restituisce una tupla di 3 elementi {:reply, reply, state}. Questo significa che il secondo elemento della tupla, una reply che può essere di qualsiasi tipo, verrà inviata al chiamante. Il terzo elemento della tupla, state, è il nuovo stato del server dopo aver gestito questo messaggio.

Esistono anche possibilità più avanzate che non tratteremo ora.

handle_cast/2

Un messaggio che non richiede una risposta può essere inviato a un processo server con GenServer.cast/2. I suoi argomenti sono identici a quelli di GenServer.call/2.

La callback handle_cast/2 si occupa di gestire quei messaggi. Riceve due argomenti, message e state, che sono gli stessi argomenti della callback handle_call/3 (tranne from).

La callback handle_cast/2 di solito restituisce una tupla di 2 elementi {:noreply, state}.

Esistono anche possibilità più avanzate che non tratteremo ora.

Devo usare call o cast?

Usa quasi sempre call, anche se il tuo codice client non ha bisogno della risposta del server.

Usare call attende la risposta, che funge da meccanismo di contropressione (per evitare che i client inviino troppi messaggi in una volta). Ricevere una risposta dal server è anche l'unico modo per essere certi che il server abbia ricevuto e gestito il messaggio del client.

handle_info/2

I messaggi possono anche finire nella casella di posta del server per vie diverse dalla chiamata a GenServer.call/2 o GenServer.cast/2, per esempio chiamando la semplice funzione send/2.

Per gestire tali messaggi, usa la callback handle_info/2. Questa callback funziona esattamente come handle_cast/2.

Il comportamento GenServer fornisce un'implementazione che intercetta tutto di handle_info/2 e registra gli errori relativi ai messaggi inattesi. Se sovrascrivi quell'implementazione predefinita, assicurati di includere sempre la tua implementazione che intercetta tutto. Se te ne dimentichi, il server andrà in crash se riceve un messaggio inatteso.

Timeout

Il valore restituito da ciascuna delle quattro callback descritte sopra può essere esteso con un ulteriore elemento della tupla, un timeout. Ad esempio, invece di restituire {:ok, state} da init/1, restituisci {:ok, state, timeout}.

Il timeout può essere usato per rilevare l'assenza di messaggi nella casella di posta per un periodo specifico. Se il server restituisce un timeout da una delle sue callback e sono trascorsi il numero di millisecondi specificato senza che sia arrivato alcun messaggio, viene chiamata handle_info/2 con :timeout come primo argomento.