I'm trying to work out in my head the best way to structure a Cocoa
app that's essentially a concurrent download manager. There's a server
the app talks to, the user makes a big list of things to pull down,
and the app processes that list. (It's not using HTTP or FTP, so I
can't use the
On Sep 20, 2009, at 8:43 AM, Sixten Otto wrote:
One way to approach this might be to create N threads, each of which
would own a connection, and wait on the request queue
You don't need concurrency or threads to handle socket connections.
The 'Mac way' is to use asynchronous I/O, hooking
On Mon, Sep 21, 2009 at 12:20 PM, Jens Alfke j...@mooseyard.com wrote:
You don't need concurrency or threads to handle socket connections. The 'Mac
way' is to use asynchronous I/O, hooking up the socket connections to the
runloop and getting callbacks when data is available.
That's true, and I
On Sep 21, 2009, at 10:14 AM, Sixten Otto wrote:
I don't think that that gets me out of the problem I was really trying
to ask about, though, which is how to manage getting the work from the
(single) queue of requests from the user to the exactly N persistent
connections available to the
On Mon, Sep 21, 2009 at 4:58 PM, Jens Alfke j...@mooseyard.com wrote:
connections available to the application. Somehow I need to track
which/how many connections are idle, and dequeue requests to those
connections.
Just keep a mutable array of free connections.
As I think about it more, I
