扭曲的+；GTK应用程序在下载文件时变得无响应

我想在同一个应用程序中使用Twisted和GTK+。我使用的是gtk2reactor，使我所有的代码都正确无阻塞，并且通常工作得很好

但是，当我运行（HTTP）下载时，GUI会变得无响应和滞后。这就好像有什么东西在扭曲的块中（在很短的时间段内），反应堆没有足够频繁地处理GTK事件。基本上，我使用：

factory = twc.HTTPDownloader(url, filename)
reactor.connectTCP(host, port, factory)

下面是一个例子来说明这个问题。我只有一个虚拟进度条来显示一些动画，但在一个成熟的程序中，这个问题也很明显。只要下载正在运行，滚动或在GtkNotebook选项卡之间切换时就会出现明显的延迟

---

这是意料之中的事，还是我做错了什么？我以前做过GTK+Twisted应用程序，从未注意到这一点，但我也从未在Twisted中传输过更大的文件（~300MB）。也许twisted选择的块大小太大，并且在将控制权返回主循环之前忙得太久（~100ms？）？我应该为GTK和twisted循环使用单独的线程吗？

在我为您提供有关修复此问题的任何建议之前，我应该注意，每当遇到这样的性能问题时，您都应该分析应用程序，以了解什么是最耗时的。您可以使用类似的分析器；或者也许，或者也许这是为了找出是什么阻碍了Twisted的反应堆。客观数据总是比猜测好，你的具体数据只能从你的具体环境中获得

也就是说，我确实有一些猜测要告诉你。这里最有可能的问题是文件I/O。非阻塞文件I/O对于Twisted来说有点棘手，因为不只是旋转线程，所以不清楚如何构造最终适合未来特定平台API的可移植API。然而，Twisted应该有一些东西可以为您抽象出线程部分

HTTPDownloader

，具体来说，这样做会使反应堆卡住，GUI冻结。您可以覆盖

pagePart

以执行非阻塞操作；但是，这意味着您需要在

HTTPPageDownloader

对象的

transport

属性上执行操作-例如，告诉它

pauseproducting

-或者如果磁盘速度较慢，您可能会在内存中缓冲该文件的所有~300MB

如果使用新的

Agent

API，您可能会发现所有这些都会变得更容易。您仍然需要执行自己的非阻塞文件I/O，但至少API将为您提供一个

transport

对象，该对象可以通过

pauseProducing

方法方便地访问，您可以直接调用该方法，而无需对多个不同的事物进行子类化，也无需经历多个抽象层（

ClientFactory

，

HTTPClientFactory

，

HTTPDownloader

，

HTTPPageDownloader

）来访问它

---

我意识到Twisted中的流控制应该更容易管理，很抱歉设置起来有点麻烦。我知道，而且

谢谢你的回答，所有的链接都非常有用！现在，我将所有gui内容放在一个单独的线程中，因为我没有流控制的经验。它现在工作得更好，尽管我不再有了twisted的好处是所有代码都在一个线程上。另外，我有点担心HTTP downloader的IO可能会使我的反应器中发生的其他事情饿死，但到目前为止还不错。GTK不能很好地处理多个线程。取决于您是如何做到这一点的，您可能会遇到奇怪的行为或崩溃。您肯定不应该再使用它了g如果您已将绞合环移动到另一个线程，请关闭GTK反应器。