4

根据我所读到的，能够将泵模式与 distcc 一起使用需要您将 make 封装在pump脚本中。但是，我的路径中没有它，我找不到它作为一个包或包含在Cygwin的distcc 包中。

但是，当我使用 distcc 编译并使用distccmon-text来监视哪些主机被联系以及它们的阶段时，我清楚地看到其中一些有时处于预处理阶段。我认为所有预处理都是在不使用泵模式时在执行 make 脚本的客户端上完成的。并且泵模式的整个想法是在远程主机上进行预处理（因此需要相同的包含文件）。

这让我很困惑。我的主要问题是： distcc 的Startup、Blocked、Connected、Preprocess、Conect、Send、Receive和Done阶段到底是什么意思？

作为一个子问题：如何在 Cygwin 中使用带有 distcc 的泵模式？

4

1 回答 1

7

distcc 的各个阶段到底是什么意思？

好的，这很尴尬，但我只是在网上浪费了四个小时试图回答这个问题。下次我只拉源码看看。但是，你提出了一个很好的观点：令人惊讶的是，这不是现成的信息。

这些是我的猜测 （因为我不想承认我浪费了四个小时没有回答这个问题！）：

  • 启动- 否则可以称为“初始化/加载”，尚未准备好执行第一个任务
  • 已阻止- 正在等待访问本地文件或本地处理器，我偶然发现
    了最近的错误修复，在等待处理器可用时将“超时”设置为一秒，并且我知道它使用零长度“ flock”文件有时阻止
  • 已连接- 进程启动与客户端的联系，现在为作业保留 (??)，或者正在编译作业 (??)
  • Preprocess - 正在执行预处理操作
  • Conect - 与客户端握手以进行原子操作，可能会被保留（？？）
  • 发送- 将编译后的目标文件发送回客户端
  • 接收- 正在接收要编译的源，或接收压缩的标头（如果使用泵模式）
  • 完成- 否则可以称为“空闲/可用”

distcc注意：由于 Google 的“泵模式”算法，在客户端（运行）和志愿者（运行）之间实际上有相当多的“握手” distccd。首先，在泵模式下，所有预期“需要”的标头都被捆绑、压缩并推送给志愿者（在那里它被解压缩到客户端机器上的本地镜像中）。然而，志愿者和客户之间的一些进一步通信似乎可以根据需要增量传输其他标头，因此可以解释上面列出的“更丰富”的通信阶段/状态。

Am I already using pump mode?

我非常怀疑它，因为您没有通过make或包装编译选项来配置它scons（需要运行 Google 算法来预测捆绑和传输给志愿者的标头使用情况），也找不到“泵”脚本. 但是，我无法解释您看到Preprocess志愿者身上的“ ”状态。（您不是指客户端上的“预处理”状态，对吗？这完全可以理解，因为默认情况下预处理在客户端上。）

相反，我认为该实现使得硬状态机可以在进入下一个状态之前通过所有状态，包括“预处理”，即使没有预处理要做。例如，即使它没有在志愿者端进行预处理，distccd 也会接收源文件，将其写入磁盘，然后启动编译器。如果您在 Cywin 上，这些都不是即时的，尤其是如果它是一个大型源文件（尤其是在其中包含所有标题之后）。因此，您可能会看到“预处理”阶段，直到它手动启动编译操作本身的下一阶段。

嘿......我没有看到明显的“编译”阶段，所以“预处理”阶段体现“编译”或“预处理和编译”是可能的（因为这些阶段通常在许多编译器中组合在一起） .

抱歉——我只是猜测。

以及如何在 Cygwin 中使用泵模式？

我没试过，但应该是可以的。显然，最常见的问题是某些 Windows 编译器在 Cygwin 下运行时Cygwin无法处理默认TMPDIR设置。distcc解决方法是将类似的东西export TMPDIR=c:/temp放入/etc/profile

常见问题解答可能会提供更多帮助： http: //distcc.googlecode.com/svn/trunk/doc/web/faq.html

于 2011-06-14T22:02:32.997 回答