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.
Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de On Feb 22, 2013, at 2:22 PM, Dave <d...@looktowindward.com> wrote: > How is threading hard in this case? Given that you have to make sure you > don't block the main thread anyway, you'd automatically do time consuming > things on a Background thread. It's as hard as [self > performSelectorInBackground..... ]; _______________________________________________ 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
