On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: > My guess is that NSOpenPanel is doing some work on a background thread, > and that work is trying to use the main queue to inform the open panel > of its completion. By using the dispatch_async approach, the main queue > is blocked, and the background thread can't inform the open panel. The > -performSelector::: approach uses a timer, so the nested invocation of > the runloop that -runModal performs is still able to dequeue the > background task completion's block off the main queue.
To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder _______________________________________________ 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
