複数のコアでコンパイルするときにmakeがハングする原因は何ですか？
昨日、ソースから [〜＃〜] root [〜＃〜] パッケージをコンパイルしようとしていました。 6コアのモンスターマシンでコンパイルしていたので、make -j 6を使用して複数のコアを使用してビルドすることにしました。コンパイルは最初はスムーズで本当に高速でしたが、ある時点でmakeが1つのコアだけで100％のCPUを使用してハングしました。
私はグーグルをして、ROOTメッセージボードに this の投稿を見つけました。このコンピュータを自分で作成したので、ヒートシンクを適切に適用しておらず、CPUが過熱しているか心配でした。残念ながら、私は仕事でここに冷蔵庫を置くことができません。;-)
lm-sensorsパッケージをインストールしてmake -j 6を再度実行し、今回はCPU温度を監視しました。高温（60℃近く）になりましたが、高温または臨界温度を超えることはありませんでした。
make -j 4を実行してみましたが、コンパイル中にmakeがハングしましたが、今回は別の場所で実行されました。
最後に、makeを実行するだけでコンパイルすると、問題なく動作しました。私の質問です：なぜそれがぶら下がっていたのですか？ 2つの異なる場所で停止したという事実のため、それはある種の競合状態が原因であったと思いますが、makeは、すべてを正しい順序で取得するのに十分なほど賢いはずだと思います。 -jオプション。
これは非常に古い質問であることに気づきましたが、それでも検索結果の上部に表示されるので、これが私の解決策です：
GNU makeには、makeを保証するジョブサーバーメカニズムがあり、その再帰的な子は、指定された数を超えるコアを消費しません。 http://make.mad-scientist.net/papers/jobserver-implementation/
すべてのプロセスで共有されるパイプに依存しています。追加の子をフォークしたい各プロセスは、最初にパイプからトークンを消費し、完了時にそれらを放棄する必要があります。子プロセスが消費したトークンを返さない場合、最上位のmakeは、それらが返されるのを待って永久にハングします。
https://bugzilla.redhat.com/show_bug.cgi?id=654822
GNU Solarisボックスでmakeを使用してbinutilsをビルドすると、「sed」がGNU sedではありません。PATHを使用してsed ==を作成するシステムよりもgsedが優先されるsedが問題を修正sedがパイプからトークンを消費した理由がわかりません。