Re: NSOpenPanel runModal on a dispatch
Re: NSOpenPanel runModal on a dispatch
- Subject: Re: NSOpenPanel runModal on a dispatch
- From: Tamas Nagy <email@hidden>
- Date: Sun, 16 Dec 2012 21:28:10 +0100
Ahh, okay, thanks for the explanation Tom, now I got it.
On Dec 16, 2012, at 9:21 PM, Tom Davie <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 (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
>
_______________________________________________
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