On 22 Feb 2013, at 13:57, Uli Kusterer wrote:

performSelector doesn't take care of locking non-threadsafe data structures, avoiding deadlocks in aforementioned logs etc. Although e.g. Cocoa's UI classes have improved a lot WRT thread-safety in recent MacOS releases, it's still not safe to drive arbitrary controls from another thread. Similar with certain libraries. By using async APIs, they take care of this for you and call you back on the main thread. It's simply letting Apple write the difficult code (and all their users find the bugs for you) instead of noticing them a year after you've shipped.

Yes, I know all that, but that's true of anything, not just a Network Manager!!!! And this isn't Apple Call Backs, I'm talking about. I've nothing against delegate type call backs.

As an example of what I mean:

-(largenumber) syncComputePIToAZillionPlaces
{

//  Compute PI for a Zillion Places - takes a long time.

return PI;
}


-(void) aSyncComputePIToAZillionPlacesWithDelegate:
{

//  Compute PI for a Zillion Places - takes a long time.

}

A (Background) thread has two choices at this stage:

1. Call aSyncComputePIToAZillionPlacesWithDelegate and provide a delegate that will be called back with the result.

2.  Call syncComputePIToAZillionPlaces get the result inline.

As long as the Background Thread doesn't have more work to do in parallel with the Compute PI operation, why is option 2 better than option 1.

I think that option 1 is by far the best solution and I can't understand why anyone would choose option 2!!

TTFN
Dave


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to