dans Erlang J'ai un superviseur-arborescence de processus, en contenant un qui accepte les connexions tcp/ip. Pour chaque connexion entrante, je génère un nouveau processus. Ce processus doit-il être ajouté à l'arbre de supervision ou non?Un processus de gestion client doit-il être ajouté à l'arborescence du superviseur?
Cordialement, Steve
Oui, vous devez ajouter ces processus à la hiérarchie de supervision car vous souhaitez qu'ils soient correctement/normalement arrêtés lorsque votre application est arrêtée. (Sinon, vous finirez par perdre des connexions qui échoueront à cause de l'arrêt de l'infrastructure d'application dont elles dépendent).
Vous pouvez créer un superviseur de stratégie simple_one_for_one, par exemple yourapp_client_sup qui a des spécifications enfants de {Id, {yourapp_client_connection, start_link_with_socket, []}, Restart, Shutdown, worker, temporary}. Le type temporary ici est important car il n'y a normalement aucune stratégie de redémarrage utile pour un gestionnaire de connexion - vous ne pouvez pas vous connecter au client pour redémarrer la connexion. temporary entraînera le superviseur à signaler la sortie du gestionnaire de connexion, mais sinon l'ignorer.
Le processus qui exécute gen_tcp:accept créera ensuite le processus de gestionnaire de connexion en effectuant supervisor:start_child(yourapp_client_sup, [Socket,Options,...]) au lieu de yourapp_client_sup:start_link(Socket, Options, ...). Assurez-vous que la fonction youreapp_client_connection:start_link_with_socket démarre l'enfant via les fonctions gen_server ou proc_lib (une exigence du module supervisor) et que la fonction transfère le contrôle du socket à l'enfant avec gen_tcp:controlling_process sinon l'enfant ne pourra pas utiliser le socket.
Une autre approche consiste à créer un processus factice yourapp_client_sup auquel les processus yourclient_connection_handler peuvent se lier au démarrage. Le processus yourapp_client_sup va juste exister pour propager EXIT messages de son parent vers les processus du gestionnaire de connexion. Il devra piéger existe et ignorer tous les messages EXIT autres que ceux de son parent. Dans l'ensemble, je préfère utiliser l'approche superviseur simple_one_for_one.
Si vous attendez que ces processus soient nombreux, il pourrait être une bonne idée d'ajouter un superviseur sous votre superviseur principal à responsabilité distincte (et peut-être utiliser le paramètre simple_one_for_one pour rendre les choses plus simples , peut-être même plus simple que votre cas actuel). En fait, si vous avez besoin de contrôler ces processus, il est toujours agréable d'avoir un superviseur. Si cela n'a pas d'importance s'ils réussissent ou non, vous n'en aurez peut-être pas besoin. Mais encore une fois, je dis toujours que c'est un codage bâclé. ;-)
La seule chose que je ne serait pas faire, c'est de les ajouter à votre arbre existant, à moins que ce soit très évident d'où ils viennent et ils sont assez peu.