Re: [OT] Sync vs ASync Server Comms
Re: [OT] Sync vs ASync Server Comms
- Subject: Re: [OT] Sync vs ASync Server Comms
- From: Jens Alfke <email@hidden>
- Date: Fri, 22 Feb 2013 14:23:58 -0800
On Feb 22, 2013, at 8:32 AM, Dave <email@hidden> wrote:
> Of course there are threading "issues"!!!! Having delegates doesn't stop that
There are no threading issues if you don’t create background threads. I’ve written a lot of code that does network access using the async APIs, and most of it didn’t require me to create any background threads. Since all my code runs on the main thread, I don’t have any threading issues. That’s one less huge thing to worry about in my app.
Scalability is another issue that I don’t think anyone else has brought up — this is the reason that async network programming has become so popular in server frameworks like Twisted and Node.js. If you want to perform N simultaneous operations with a synchronous API, you have to spawn N threads. As N increases, this gets expensive: threads consume kernel resources and eat up address space for their stacks. With an async API, you can do the same work on a single thread. (And no, the OS does not create N threads behind your back to service the async API; it uses kqueues to manage any number of async tasks from a single background thread.)
> You don't have to take the example so literally! If I called the methods:
>
> -(someValue) syncGetValueFromServer
> {
> // Get Value From Server - takes a long time.
> return Value;
> }
>
> -(void) aSyncGetValueFromServer:
> {
> // Get Value From Server - takes a long time.
> }
>
> It would amount to exactly the same thing! You are making a common mistake of making conclusions about the method you are calling!
No, it wouldn’t be the same. The “aSyncGetValueFromServer” method would return immediately, letting me get on with other work on that thread. That’s what “asynchronous” means.
Dave, it’s kind of rude to ask the list for advice/insight, then start yelling at us when you don’t like our opinions (especially when a lot of the people replying have a lot more Cocoa experience than you seem to.)
—Jens
_______________________________________________
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