可可、Windows 和线程？

Question

在 Windows 上，每个线程都有一个消息队列，每个消息队列都会为该线程拥有的窗口处理消息。 这意味着编写一个应用程序非常简单，您可以在其中创建一个线程、一个消息循环和一个（或多个）窗口。忽略任何类型的应用程序问题，现在一个应用程序窗口将继续与用户交互，即使其他窗口之一忙于某种模式操作。

现在，在将应用程序移植到 cocoa 时，我遇到了 Interface Builder。对于希望更多地控制窗口创建和消息循环构造的人来说，这是一个惊喜。尽管如此，我还是能看出 IB 是从哪里来的。

然而，我的问题在于不透明的函数 NSApplicationMain()。这 - 在应用程序主线程上，自动创建应用程序主窗口，并运行消息泵，所有数据都来自 NIB 文件。

然而，这给我留下了一个问题：即使我相信 Interface Builder 是制作我的主应用程序窗口的方法——而且我已经找到了足够的目标 C 来动态创建子窗口——以及如何创建线程 - 我可以看到如何在工作线程中创建消息泵。我开始怀疑它的可能性。

cocoa 中的窗口是否甚至具有它们在 Win32 中的那种线程亲和性？即每个线程都有自己的消息调度循环，用于该线程拥有的窗口？我开始怀疑 Cocoa 可能希望我的所有窗口都由主线程“拥有”，而我只是将工作（和绘图）偏移到其他线程上。

关于如何最好地将多窗口每线程 Win32 应用程序转换为 Cocoa 范例的任何线索？

Answer 1

Interface Builder 是本次讨论中的一个红鲱鱼。真正的问题以 Cocoa 的设计模式为中心，您问题中的这两段是关键：

然而，这给我留下了一个 问题：即使我认同这个想法 Interface Builder 是 去制作我的主应用程序窗口 - 和 我已经想出了足够多的目标 C 即时创建子窗口 - 作为 以及如何创建线程 - 我 可以看到如何创建消息泵 在工作线程中。我开始怀疑 有可能。

可可中的窗户也有那种吗 他们在 Win32 中的线程亲和力？ 即每个线程都有自己的消息 由拥有的窗口的调度循环 那个线程？我开始怀疑 也许可可期待我所有的 窗户由主“拥有” 线程，我只是去抵消工作 （和绘图）到其他线程上。

简而言之，不，它不是那样工作的。 Cocoa 有一个完全不同的事件处理模型和一套完全不同的支持并发的工具。

值得注意的是，Cocoa 有一个强烈的主事件循环 概念，它始终 在主线程上运行。这是处理用户事件的地方，也是几乎所有绘图发生的地方（尽管随着时间的推移，这种限制已经放松）。

这是不同的，试图将其弯曲以使其像带泵的每个窗口的线程一样工作是一条极度痛苦的道路。不要往下走。

现在，Cocoa 确实每个线程都有运行循环。但它们不用于处理用户事件。

简而言之，您将需要重新审视应用程序的架构，以将代码拉入 Cocoa。直接端口是不可能的。