Mon apprentissage de Erlang

[Sephi-Chan]

Et bien ! Je ne pensais pas à avoir autant de difficulté pour simplement démarrer un nouveau superviseur (qui supervisera les vaisseaux) en tant qu'enfant du superviseur principal.

https://github.com/Sephi-Chan/battleflee...42e4538af5

J'ai donc modifié le superviseur principal pour qu'il lance à son tour un superviseur de type ship_sup. L'idée étant de créer un arbre de supervision.

-module(battlefleet_sup).

-behaviour(supervisor).

-export([ start_link/1, init/1 ]).



%% API.

start_link(Args) ->

  supervisortart_link({ local, ?MODULE }, ?MODULE, Args).





%% Callbacks.

init(_Args) ->

  RestartStrategy = { one_for_one, 10, 60 },

  ShipSup = { ship_sup, { ship_sup, start_link, [] }, permanent, infinity, supervisor, [ ship_sup ] },

  { ok, { RestartStrategy, [ ShipSup ] } }.

Ici, on peut voir que j'ajoute une définition à la liste des processus enfants du superviseur.

Détaillons un peu de quoi est constitué une définition. Déjà, on peut voir que c'est un tuple de 6 éléments.

• Le premier élément est un identifiant interne du superviseur. Cet identifiant doit être unique et permet ainsi d'éviter qu'un autre enfant similaire soit lancé (a priori, on ne voudrait pas avoir 2 superviseurs identiques) ;
  
• Le second est un tuple de 3 éléments :
  • Le nom du module du superviseur ;
    
  • Le nom de la fonction à exécuter pour lancer le processus ;
    
  • La liste des arguments d'initialisation du processus. Ici, aucun argument (je le précise car ça m'a bloqué pendant au moins une heure : je pensais que ça transmettait une liste vide) ;
    
• Le suivant indique le mode de vie du processus. Celui-ci est un processus permanent qui devra toujours être relancé s'il s'arrête ;
  
• Vient ensuite le délai de lancement. Comme c'est un superviseur, on lui laisse tout le temps dont il a besoin ;
  
• Enfin vient la liste des modules dépendants. C'est utilisé pour le hot code swapping (la modification du code sans arrêter l'application) ;
  

Il faut ensuite implémenter le module ship_sup.

-module(ship_sup).

-behaviour(supervisor).

-export([ start_link/0 ]).

-export([ init/1 ]).





start_link() ->

  supervisortart_link({ local, ?MODULE }, ?MODULE, []).





init(_Args) ->

  { ok, { { one_for_one, 10, 60 }, [] } }.

Il s'agit donc d'un superviseur tout simple qui ne supervise rien pour le moment.

Pendant 1 heure, j'ai donc eu un plantage au démarrage de l'application car je pensais que start_link était appelé avec 1 argument (une liste vide). Alors que OTP l'appelait en fait sans argument.

Plus qu'à créer un module pour créer des vaisseaux, les faire persister et les faire bouger.