Re: NSOpenPanel runModal on a dispatch
Re: NSOpenPanel runModal on a dispatch
- Subject: Re: NSOpenPanel runModal on a dispatch
- From: Kyle Sluder <email@hidden>
- Date: Sun, 16 Dec 2012 11:39:58 -0800
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 (email@hidden)
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:
This email sent to email@hidden