1

gen_fsm プロセスの pid に送信されたメッセージは、状態コールバックでイベントとして一致することに気付きました。これは単なる偶然ですか、それともこの機能に頼ることができますか?

通常、gen_fsm に送信された一般的なメッセージが handle_info/3 コールバックに表示されることを期待し、gen_fsm:send_event を使用して再送信する必要があると考えていました。

gen_fsm はメッセージを最初に状態コールバックに一致させ、次に常に handle_info/3 コールバックに一致させようとしますか? それとも、状態コールバック句に一致しない場合のみですか?

ただし、試してみると、デバッグ出力によると、メッセージが2回処理されているようです。

したがって、基本的には、次のように質問することもできます: 受信したメッセージを gen_fsm 状態関数のイベントとして正しく処理する方法は?


明確化:メッセージが渡されることによってイベントの一部が発生していることは、この質問に与えられていると見なす必要があります。

多くの場合、fsm への関数呼び出しのみを使用してプロトコルを可視化する方がクリーンであることは承知しています。

これが、前述の gen_fsm が適合しなければならない現在のフレームワークを改善するかどうかはよくわかりません。各層が connect() 関数を呼び出して下位層をアタッチする (場合によっては開始する) 多様なプロトコル スタック。パケットは、関数を呼び出すことで下位層に送信され (send) receive、メッセージを送信することで受信されます。gen_tcp によく似ています。

gen_fsm のコードを見ると、一般的なメッセージは handle_info にのみ渡されることがわかったので、問題は、handle_info/3 コールバックから状態関数を直接呼び出すか、gen_fsm:send_event を使用して再送信するかだけです。

4

1 に答える 1

1

コードに次のようなものがない限り、一般的なメッセージは handle_info コールバックによって処理されます。

handle_info(情報、状態名、状態データ) -> ?MODULE:状態名(情報、状態データ)。

これは再送信を回避しますが、それも再送信もお勧めしません。

send_event/sync_send_event/send_all_state_event/sync_send_all_state_event をカプセル化する API 呼び出しによって排他的にイベントを配信すると、プロトコルが明示的になります。edoc を使用すると、理解、維持、および文書化が容易になるため、これは正しいことです。

于 2010-10-18T19:33:53.970 に答える