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