私は、本質的に同時ダウンロード マネージャーである Cocoa アプリを構築するための最善の方法を頭の中で考え出そうとしています。アプリが通信するサーバーがあり、ユーザーはプルダウンするものの大きなリストを作成し、アプリはそのリストを処理します。(HTTP や FTP を使用していないため、URL 読み込みシステムを使用できません。ソケット接続を介して話します。)
これは基本的に、古典的な生産者と消費者のパターンです。秘訣は、コンシューマーの数が固定されており、永続的であることです。サーバーは、開くことができる同時接続数 (通常は少なくとも 2 つ) に厳密な制限を設定し、新しい接続を開くにはコストがかかるため、理想的な世界では、同じ N 個の接続がアプリの存続期間にわたって開かれます。
これにアプローチする 1 つの方法は、それぞれが接続を「所有」する N 個のスレッドを作成し、リクエスト キューで待機し、空の場合はブロックすることです。接続数が膨大になることはないため、実際のシステム オーバーヘッドの観点からは、これは不合理ではありません。しかし、概念的には、Cocoa はより洗練されたソリューションを提供する必要があるようです。
を使用して、接続数でNSOperationQueue呼び出すことができるようです。setMaxConcurrentOperationCount:次に、ダウンロード リクエストをそのキューに放り込みます。しかし、その場合、接続自体を管理する方法がわかりません。（それらをスタックに置き、キューに依存して、オーバー/アンダーランしないようにしますか？スタックと一緒にディスパッチセマフォを投入しますか？）
Grand Central Dispatchというすばらしい新しい世界にいる今、これに取り組む他の方法はありますか? GCD の主力機能である同時実行性を動的にスケーリングする機能 (および、 Changing Producer-Consumer Implementationsに関する Apple の推奨事項で言及されている) は、実際には役に立たないため、一見したところ、そうは思えません。しかし、私はそれについて読むことの表面をかじっただけです。
編集：
重要な場合: はい、サーバーとの実際の通信を行うために、非同期/ノンブロッキング ソケット API を使用することを計画しています。したがって、I/O 自体は独自のスレッドである必要はありません。私が関心を持っているのは、作業を待ち行列に入れ、(安全に) 接続が利用可能になったときにそれを接続に渡す仕組みだけです。