distcc のフェーズとは正確には何を意味するのでしょうか?
わかりました、これは恥ずかしいことですが、私はその質問に答えるためにウェブで 4 時間を無駄にしました. 次回はソースを引っ張って見てみます。しかし、あなたは良い点を挙げています。これがすぐに入手できる情報ではないのは驚くべきことです。
これらは私の推測です （質問に答えずに4時間を無駄にしたことを認めたくないからです！）：
- 起動- 「初期化/読み込み」と呼ばれることもあり、まだ最初のタスクの準備ができていません
- ブロック- ローカル ファイルまたはローカル プロセッサへのアクセスを
待機しています。最近のバグ修正で、プロセッサが使用可能になるのを待つ間、「タイムアウト」が 1 秒に設定されているのを見つけました。長さ 0 の " flock" ファイルが使用されていることを認識しています。ときどきブロックする
- 接続済み - クライアントとの接続を開始したプロセス、ジョブ用に予約されている (??)、またはジョブをコンパイル中 (??)
- 前処理- 前処理操作を実行しています
- Connect - アトミック操作のためのクライアントとのハンドシェイクです。おそらく予約されます (??)
- 送信- コンパイルされたオブジェクト ファイルをクライアントに送り返しています
- 受信- コンパイルするソースを受信しているか、圧縮されたヘッダーを受信しています (ポンプモードを使用している場合)
- 完了- それ以外の場合は「アイドル/利用可能」と呼ばれる可能性があります
distcc注: Google の「ポンプ モード」アルゴリズムにより、実際には、クライアント (実行中) とボランティア (実行中)の間でかなりの「ハンドシェイク」が発生しますdistccd。まず、ポンプ モードでは、「必要」であると予想されるすべてのヘッダーがバンドルされ、圧縮され、ボランティアにプッシュされます (クライアント マシン上のようなローカル ミラーに解凍されます)。ただし、ボランティアとクライアントの間のさらなる通信により、必要に応じて他のヘッダーを段階的に転送できるように思われるため、上記の「よりリッチな」通信フェーズ/状態を説明できます。
Am I already using pump mode?
makeコンパイル オプションをorでラップして構成しなかったためscons(ボランティアへのバンドルとトランスポートのヘッダーの使用を予測するために Google アルゴリズムを実行する必要があります)、「ポンプ」スクリプトを見つけることもできません。 . Preprocessしかし、ボランティアの「 」状態を見た理由を説明することはできません。(クライアントの「前処理」状態について言及しているわけではありませんよね? デフォルトでは前処理はクライアント上にあるため、それは完全に理解できます。)
むしろ、実装により、ハードステートマシンが次の状態に進む前に、実行する前処理がない場合でも、「前処理」を含むすべての状態を通過できるようになると思います。たとえば、ボランティア側で前処理を行わなかったとしても、distccd はソース ファイルを受け取り、それをディスクに書き込み、コンパイラを起動します。Cywin を使用している場合、特にソース ファイルが大きい場合 (特に、すべてのヘッダーが含まれている場合)、それらは瞬時に発生しません。そのため、コンパイル操作自体の次のフェーズを手動で開始するまで、「前処理」フェーズが表示される場合があります。
ちょっと...明らかな「コンパイル」フェーズが表示されないため、「前処理」フェーズが「コンパイル」または「前処理とコンパイル」を具体化する可能性があります（とにかく、これらのフェーズは多くのコンパイラで組み合わされることが多いため） .
申し訳ありませんが、推測です。
Cygwinでポンプモードを使用するにはどうすればよいですか?
私はそれを試していませんが、それは可能であるはずです。どうやら最も一般的な問題Cygwinは、一部の Windows コンパイラがCygwin で実行されTMPDIRたときにデフォルト設定を処理できないことです。distcc修正は、次のようなものを入れることexport TMPDIR=c:/tempです/etc/profile
FAQ がさらに役立つかもしれません: http://distcc.googlecode.com/svn/trunk/doc/web/faq.html