Ahh, okay, thanks for the explanation Tom, now I got it. On Dec 16, 2012, at 9:21 PM, Tom Davie <tom.da...@gmail.com> wrote:
> Performing asynchronously and blocking the main *queue* are not related > things. > > The main queue is a serial queue, it only executes one block at a time. At > the moment, it's executing your block, stuck in your runModal call. That > runModal call will not come off the stack, and the block finish executing > until the open dialog is closed. > > If the openDialog methods dispatch to the main queue, their dispatches will > not occur until the main queue is able to run another block, which won't > happen until your block finishes. > > You are very much blocking the main queue. > > Thanks > > Tom Davie > > On 16 Dec 2012, at 20:04, Tamas Nagy <tamas.lov.n...@gmail.com> wrote: > >> 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/tom.davie%40gmail.com >> >> This email sent to tom.da...@gmail.com > _______________________________________________ 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
