我正试图围绕这个秘籍中发生的事情展开思考，因为我正计划实现一个与此类似的 wx/twisted 应用程序（即 wx 和 twisted 在单独的线程中运行）。我知道twisted 和wx 事件循环都需要以线程安全的方式访问（即reactor.callFromThread、wx.PostEvent 等）。我要质疑的是，将在一个线程中实例化的对象的实例方法（在本配方的情况下为 GUI 线程）作为在单独线程中运行的反应器的延迟 callBack 和 errBack 方法传入的线程安全性。这是一个好主意吗？
twisted 中有一个 wxreactor 可用，但谷歌搜索显示，自从它被引入库以来，它已经出现了许多问题。即使是最初提出 wxreactor 技术的人，也主张在单独的线程中运行 wx 和扭曲。
我还没有找到这种技术的任何其他例子，但我很想看到一些。
只要您正确地同步这些实例的最终销毁，在线程之间传递实例方法的唯一行为是安全的（线程共享内存，因此哪个分配/初始化它的一部分实际上并不重要）。
整体线程安全取决于这些方法的实际作用，所以只要让它们“玩得好”就可以了。
我不会说这是一个“好主意”。您应该使用 wxreactor 在同一个线程中运行反应器和 GUI。
Schroeder 先生描述的计时器驱动的事件循环饥饿方法是实现事件循环集成的最糟糕的故障安全方法。如果你使用wxreactor(not wxsupport) Twisted 现在使用一种方法，在内部将多路复用分流到线程，这样就不需要使用计时器了。更好的是让 wxpython 公开wxSocket并让某人在其上建立一个反应器。
但是，如果您设置使用单独的线程与 Twisted 通信，要记住的一件事是，虽然您可以使用源自您喜欢的任何线程的对象作为传递给的值Deferred.callback，但您必须只调用 Deferred.callback反应堆线程本身。延迟不是线程安全的；多亏了一些调试工具，甚至这个Deferred 类都不是线程安全的，所以你在使用它们时需要非常小心，不要离开 Twisted 主线程。即当你在 UI 线程中有结果时，使用reactor.callFromThread(myDeferred.callback, myresult).