Comment redémarrer l'enfant avec l'état personnalisé à l'aide du comportement de superviseur Erlang OTP?

Sans connaître aucun détail sur ce que vous faites, je peux imaginer un monde où ce qui suit a du sens:

1. Le superviseur crée une table ETS et transmet l'identifiant de la table à chaque enfant
2. Un processus enfant commence et, sur la base d'un attribut pertinent de l'enfant, consulte la table ETS pour rechercher l'état de chargement
3. Chaque fois que l'état d'un enfant change, il l'écrit à la table ETS

   Donc, si j'avais 12 processus d'enfants représentant les 12 tribus de Cobol utiliserait chacun son nom comme la clé de la table ET pour rechercher l'état laissé par une précédente incarnée au début. Et chaque processus mettrait à jour le tableau (à nouveau en utilisant son nom comme clé) chaque fois que son état a changé.

   Le superviseur redémarrera automatiquement un enfant tué et une étape 2 ci-dessus, serait exécuté dans la méthode init de l'enfant. L'étape 3 serait traitée dans les méthodes de la poignée_call des enfants, de la poignée et du gare_info (je fais des hypothèses sur la nature de vos processus). Un certain nombre de stratégies de redémarrage sont disponibles via le superviseur qui peut même redémarrer les frères et sœurs si désiré.

   J'espère que cela vous donne des pensées.

éventuellement redémarrer avec le même état n'est pas une bonne idée. Probablement mauvais processus d'état d'état d'état de crash et si vous redémarrez avec le même état, il se bloquera à nouveau. Mais si vous le souhaitez, utilisez la ressource externe pour le garder (comme ETS ou MNSIA).

Je pense que ce type de personnalisations du comportement du superviseur OTP ne peut pas être fait facilement. La façon dont les superviseurs OTP sont conçues me force à suivre certaines pratiques de conception strictes. Le plus important dans ce cas est que le superviseur ne devrait rien faire d'autre en dehors de la surveillance de ses enfants et de les redémarrer en cas de résiliation anormale. Il ne devrait y avoir aucune logique supplémentaire dans le superviseur de ne pas introduire de bugs dans les superviseurs qui font partie essentielle de l'arborescence de la supervision et de la tolérance aux pannes.

lorsque l'enfant meurt, je veux le redémarrer avec le même état qu'il avait avant le crash fort> - C'est une mauvaise pratique en général parce que l'enfant aurait pu être mort en raison de l'état corrompu qu'il avait avant la résiliation et le redémarre avec le même état dans ce cas entraînera sûrement des problèmes p>

y a-t-il une norme approche en cas de tel? strong> Personnalisation de l'état des enfants au sein du superviseur, avant de les redémarrer, contre les bonnes pratiques de conception du superviseur. Par conséquent, ce type de tâches se fait généralement différemment, par exemple en introduisant un autre processus, par exemple Gen_Server, qui serait responsable de la création d'enfants via Superviseur (superviseur: start_child) et maintenir des moniteurs sur tous les processus. Ce processus supplémentaire pourrait faire toutes les personnalisations requises avant de commencer nouvel enfant. P>

Comment obtenir PID du processus de terminaison à l'aide de OTP? strong> - Dans le processus supplémentaire qui commence les enfants via superviseur: start_child Vous pouvez les surveiller, puis écouter des messages vers le bas. Par exemple, dans le cas de GEN_SERVER, vous utiliseriez la fonction GRAND_INFO comme ci-dessous: P>

handle_info({'DOWN', Ref, process, _Pid, _}, S) -> 
    handle_down_worker(Ref, _Pid, S).