Puis-je gérer un message reçu dans les rappels d'état gen_fsm?

Question

J'ai remarqué que les messages envoyés au pid d'un processus gen_fsm sont mis en correspondance dans les rappels d'état en tant qu'événements. Est-ce juste accidentel ou puis-je me fier à cette fonctionnalité?

Normalement, je m'attendais à ce que les messages généraux envoyés à un gen_fsm apparaissent dans le rappel handle_info/3 et je pensais que je devais le renvoyer en utilisant gen_fsm: send_event. Est-ce que gen_fsm essaie de faire correspondre le message d'abord avec le rappel d'état, puis avec le rappel handle_info/3? Ou seulement s'il ne correspond pas à une clause de rappel d'état?

Cependant quand je l'essaye mon message semble être traité deux fois selon la sortie de débogage. Donc, fondamentalement, la question peut également être posée comme: comment gérer correctement les messages reçus en tant qu'événements dans les fonctions d'état de gen_fsm?

---

Précision: que certains des événements se produisent en obtenant les messages transmis devraient être pris en considération donnée à cette question.

Je suis conscient que dans de nombreux cas, son nettoyeur rend le protocole visible en utilisant des appels de fonction dans le fsm seulement. Je ne suis pas sûr si cela améliorerait le cadre actuel où le gen_fsm mentionné doit s'intégrer: Diverses piles de protocoles où chaque couche appelle une fonction connect() pour attacher (et parfois démarrer) la couche inférieure. Les paquets sont envoyés aux couches inférieures ba appelant une fonction (envoi) et reçus par receive un message. Tout comme gen_tcp. En regardant le code pour gen_fsm, j'ai déjà compris que les messages généraux ne sont transmis qu'à handle_info, donc seule la question reste d'appeler la fonction state directement depuis le callback handle_info/3 ou de renvoyer gen_fsm: send_event.

Answer 1

messages généraux sont traités par le rappel handle_info, sauf si vous avez quelque chose comme ceci dans votre code:

handle_info (Info, StateName, StateData) -> MODULE: StateName (Info, StateData).

Ce qui évite de renvoyer, mais je ne le recommande pas, ni ne le renvoie.

La livraison d'événements exclusivement au moyen d'appels d'API encapsulant send_event/sync_send_event/send_all_state_event/sync_send_all_state_event rend le protocole explicite. Ce qui est une bonne chose, car il est plus facile de comprendre, de maintenir et de documenter avec edoc.