Re: Architecture for concurrent network client
Re: Architecture for concurrent network client
- Subject: Re: Architecture for concurrent network client
- From: Sixten Otto <email@hidden>
- Date: Mon, 21 Sep 2009 13:14:19 -0400
On Mon, Sep 21, 2009 at 12:20 PM, Jens Alfke <email@hidden> 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 knew better than that. For the actual I/O part of
this, I'm definitely planning to let the system handle all of the
asynchronicity as you suggest. That seems to be pretty well-traveled
ground in terms of discussion and code libraries, so I'm hopeful I can
work that out on my own. :-)
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 application. Somehow I need to track
which/how many connections are idle, and dequeue requests to those
connections.
Sorry for muddying the waters!
Sixten
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden