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 
> <cocoa-dev@lists.apple.com> 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 
>> <cocoa-dev@lists.apple.com> 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 (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/zav%40mac.com
>> 
>> This email sent to z...@mac.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/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.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

Reply via email to