0

「monitor_node」と呼ばれるプロセスの階層があります。これらの各 monitor_nodes は、1 つのスーパーバイザによって監視されます。

さて、これらのノードのそれぞれは、複雑な内部構造を持つ場合があります。つまり、適切に動作するために必要ないくつかのサブプロセスがある場合とない場合があります。例: keep-alive メッセージを送信するプロセス。これまでのところ、プレーンな spawn_link を使用してこれらの「内部」プロセスを作成してきました。

しかし、monitor_node (監視されている) の init 関数でそれらを生成すると、この関数が失敗することがあります (したがって、スーパーバイザー ツリー全体が失敗します)。私の質問は、これらの内部プロセスをスーパーバイザー ツリーに接続することは良い解決策でしょうか? monitor_node を内部プロセスを監視するスーパーバイザーに変更することを考えています。

私の疑問は次のとおりです。

  1. 非常に多くの非常に小さなプロセスを監視する必要があります。これが良い習慣かどうかはわかりません。

  2. 特定の「内部」プロセスが単純なプロセスであるか、何らかの内部構造を持っている（他のプロセスも生成する）ことを事前に知らない場合があります。後者の場合は、おそらくこれらの「内部内部」プロセスをスーパーバイザー ツリーにアタッチする必要があります。

あまり混乱していないことを願っています。答えを楽しみにしています。

編集：

非常によく似た（同じではないにしても）問題がここで議論されています（3番目の投稿）。与えられた解決策は、I GIVE CRAP ANSWERS が与えたものとほとんど同じです。

4

1 に答える 1

2

スーパーバイザー:

ここには、2 つのスーパーバイザーの使用を含むトリックがあります。あなたの木は次のようになります：

main_sup -> worker
main_sup -> attached_pool_sup

attached_pool_sup -> workers

main sup はone_for_allであるため、ワーカーまたはプールのスーパーバイザーが死亡した場合、ツリーは終了し、殺されます。プール スーパーバイザーは、simple_one_for_one数百または数千のワーカーを持つのに適しています。

初期化：

init コールバックであまり多くの作業を行わないでください。スーパーバイザーは init が完了するまで待機し、通常よりも時間がかかる場合はタイムアウトを設定できます (ケースによっては増やすことができます)。

トリックは、すばやくタイムアウトし (init からタイムアウト 0 で戻る)、handle_infoタイムアウト コールバックで追加のセットアップを処理することです。そうすれば、メインのスーパーバイザーを停止することはありません。ここでレースに注意してください！

于 2011-05-17T08:49:11.963 に答える