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
