我试图在脑海中找出构建 Cocoa 应用程序的最佳方法，该应用程序本质上是一个并发下载管理器。应用程序与服务器进行通信，用户列出一个要下拉的大列表，然后应用程序处理该列表。 (它不使用 HTTP 或 FTP，因此我无法使用 URL 加载系统；我将通过套接字连接进行讨论。)
这基本上是经典的生产者-消费者模式。诀窍在于消费者的数量是固定的，而且他们是持久的。服务器对可以打开的同时连接数设置了严格的限制(尽管通常至少有两个)，并且打开新连接的成本很高，因此在理想情况下，在应用程序的生命周期中打开相同的 N 个连接。
解决这个问题的一种方法可能是创建 N 个线程，每个线程都“拥有”一个连接，并等待请求队列，如果队列为空则阻塞。由于连接数量永远不会很大，因此就实际系统开销而言，这并非不合理。但从概念上讲，Cocoa 似乎必须提供更优雅的解决方案。
看来我可以使用 NSOperationQueue ，并使用连接数调用 setMaxConcurrentOperationCount: 。然后我将下载请求放入该队列中。但我不确定在这种情况下如何管理连接本身。 (只需将它们放在堆栈上，并依靠队列来确保我不会运行过度/不足？将 dispatch semaphore 与堆栈一起放入？)
现在我们正处于 Grand Central Dispatch 的美丽新世界，这是否开辟了解决这个问题的其他方法？乍一看，似乎并非如此，因为 GCD 动态扩展并发的旗舰能力(并在 Apple 关于 Changing Producer-Consumer Implementations 的建议中提到)实际上对我没有帮助。但我刚刚读到了它的皮毛。
编辑:
如果重要的话:是的，我计划使用异步/非阻塞套接字 API 来与服务器进行实际通信。因此 I/O 本身不必位于其自己的线程上。我只关心对工作进行排队的机制，并在连接可用时(安全地)将其分发给连接。
最佳答案
如果您使用 CFSocket 的非阻塞 I/O 调用，我同意，这一切都应该发生在主线程上，让操作系统处理并发问题，因为您只是复制数据而不是真正执行任何操作计算。
除此之外，听起来您的应用程序唯一需要做的其他工作就是维护要下载的项目队列。当任何一个传输完成时，CFSocket 回调可以启动队列中下一项的传输。 (如果队列为空，则减少连接计数，如果将某些内容添加到空队列，则开始新的传输。)我不明白为什么您需要多个线程。
也许您遗漏了一些重要的内容，但根据您的描述，该应用程序受 I/O 限制，而不是 CPU 限制，因此所有并发内容只会生成更复杂的代码，而对性能的影响最小。
这一切都在主线程上完成。
关于cocoa - Cocoa 中的并发网络客户端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1449685/