Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this.
On Dec 16, 2012, at 8:39 PM, Kyle Sluder <k...@ksluder.com> wrote: > 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
