私は、4 つの「マネージャー」(それ自体のサーバー プロセス) を fork / exec して初期化し、クライアントからの接続を受け入れ、「スレーブ」をfork / execしてクライアントと通信するサーバーを設計しています。存続期間中、スレーブはマネージャーとの接続を確立し、マネージャーに作業要求を送信します。
私の質問は、マネージャーの立ち上げについてです。それぞれの初期化には時間がかかる場合があり (数分)、マスターサーバーが初期化されるまでクライアントの受け入れを続行したくありません。これを行う最良の方法は何ですか？マネージャーが準備ができたときにマスターサーバーに信号を送ることを検討する必要がありますか? マネージャーにマスターへのソケット接続を作成させる必要があります-おそらくクライアントが接続するポートとは異なるポートで-準備ができたらメッセージを送信しますか? または、他の何か？
4 つのマネージャーをフォークする前に、パイプを 1 つ作成したくなるでしょう。マネージャーの準備ができたら、パイプに PID を書き込んで閉じることができます。マスターサーバーは、少なくとも 1 つのマネージャーが準備完了を示すまで、待機ポートを開くのを遅らせることができます。すべてのマネージャーが現役の準備ができていることを報告する前にパイプから EOF を取得した場合、マネージャーの少なくとも 1 つが起動に失敗したことを認識し、適切なアクション (エラーをログに記録して終了しますか?) を実行できます。パイプに書き込まれたメッセージは通常、アトミックに処理されます。つまり、メッセージが十分に短い場合、あるプロセスが書き込む内容は、別のプロセスが書き込む内容とインターリーブされません。
一部のバリエーションでは、マネージャーごとに 1 つのパイプを使用できます。次に、メッセージを待機しているパイプをポーリングまたは選択する方法を決定する必要があります。マネージャーが準備ができていることを示した後、パイプを閉じないように決定することもできます。彼らはそれを開いたままにし、準備ができたら適切な「PID準備完了」を書き込み、他のステータスメッセージ（「PID終了中」、「PIDがビジー状態」、「PID休憩中」など）を後で書き込みます。
他にも使用できる IPC メカニズムは多数あり、それぞれに独自の長所と短所があります。マネージャーがマスターに何を伝える必要があるか (およびマスターが特定のマネージャーとやり取りする必要があるかどうか) に大きく依存します。ソケットは確実に使用できます。メッセージ キューも同様です。通信のニーズが単純な場合は、セマフォ セットが機能する可能性があります。そして、リストは続きます。
あなたが考えているのはFIFOパイプです。mknodは伝統的にそれらを作成するために使用されます。パイプには2つのファイル記述子があり、1つは読み取り用、もう1つは書き込み用です....必要に応じてブロックできます...