彼のページ紹介これ自己管理技術、Dan Bernsteinは、信号の観点から競合状態を説明し、select()解決策を提供し、次のように結論付けます。
もちろん、正しい方法は
fork()プロセスIDではなくファイル記述子を返すことです。
これが意味するのは、select()このような状態変更の通知を受け取るためにシグナルハンドラを使用する代わりに、子プロセスの状態変更を自分で処理することは可能ですか？
ベストアンサー1
問題はソースコードで説明されており、select()thisなどの信号で中断する必要がありますSIGCHLDが、場合によっては正しく機能しません。したがって、解決策は信号をパイプに書き込み、それを監視することですselect()。ファイル記述子の監視は、この問題を解決するように設計されていますselect()。
回避策は、デフォルトでシグナルイベントをファイル記述子イベントに変換します。 fdが最初に返されると、fork()回避策は必要ありません。対応するfdはおそらく一緒に直接使用できるからですselect()。
はい、最後の段落の説明が私の考えに合うようです。
fd（または他のタイプのカーネルハンドル）が通常のプロセスID番号よりも良いもう1つの理由は、プロセスが終了した後にPIDを再利用できることです。場合によっては、プロセスにシグナルを送信するときに問題が発生する可能性があり、そのプロセスが同じPIDを再利用する他のプロセスではなく、考えているプロセスであることを確認することは不可能です。 （子プロセスにシグナルを送信するときにこれが問題になるとは思いませんが、wait()PIDを解放するには親プロセスを子プロセスで実行する必要があるためです。）