Re: Open a panel in secondary thread?
Re: Open a panel in secondary thread?
- Subject: Re: Open a panel in secondary thread?
- From: "Glenn L. Austin via Cocoa-dev" <email@hidden>
- Date: Mon, 23 Mar 2020 08:47:15 -0700
Correct.
main_queue will *always* be on the main thread, but the main thread may be
running a different queue at any specific point in time.
So, if you're *not* on the main thread, throwing code over to the main queue to
execute will guarantee that it's on the main thread - but not vice-versa.
> On Mar 23, 2020, at 8:25 AM, Alex Zavatone via Cocoa-dev
> <email@hidden> wrote:
>
> Main queue is analogous to the main thread, but not exactly the same -
> according to Apple’s docs.
>
> Sent from my iPhone
>
>> On Mar 23, 2020, at 12:53 PM, Gabriel Zachmann via Cocoa-dev
>> <email@hidden> wrote:
>>
>> Thanks a lot for your response.
>>
>>> I would not do this. It is widely documented that AppKit API that produce
>>> UI elements, like NSOpenPanel, are _not_ thread safe.
>>
>> Right, and that is why I have to execute any UI code in the main thread,
>> or so I thought.
>> As far as I understand, the dispatch_get_main_queue is executed by the main
>> thread, isn't it?
>>
>>
>>> So you may find your app hitting some memory stomping issues or strange
>>> crashes/exceptions due to this. Specifically what problems you will hit
>>> are anyones guess, but its just a matter of time. There is a reason Xcode
>>> has the Main Thread Checker to catch UI elements being used on secondary
>>> threads.
>>>
>>> Lets come at this from a different direction: What are you trying to do?
>>> Why do you think you need to use the open panel on a secondary thread?
>>
>> When the user selects a directory, I collect all files in that sub-tree (aka
>> "scan").
>> That might involve aliases. which means I need to ask the user to open the
>> directory that alias points to.
>> Because that scan can take several seconds (10-20),
>> I wanted to do that scan in a secondary thread so that it can update
>> progress info in the UI.
>>
>> Best regards, Gabriel
>>
>> _______________________________________________
>>
>> 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
_______________________________________________
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