Re: Open a panel in secondary thread?
Re: Open a panel in secondary thread?
- Subject: Re: Open a panel in secondary thread?
- From: Sandor Szatmari via Cocoa-dev <email@hidden>
- Date: Mon, 23 Mar 2020 09:05:57 -0400
Gabriel,
> On Mar 23, 2020, at 8:54 AM, 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?
Yes
>
>
>> 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.
This is all reasonable… I guess there may be two options, ask the user on the
main thread, before you are on your background thread, and only start the
background thread after the user answers, or dispatch the UI work to the main
thread from your background thread as your code sample showed.
The fact you have to block (dispatch_sync) your background thread sort of leads
me to think you could be avoiding the extra care needed to run things on the
main thread by calling in before you start your background thread.
Sandor
>
> 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