Re: waitUntilDone: parameter when performing selector on main thread
Re: waitUntilDone: parameter when performing selector on main thread
- Subject: Re: waitUntilDone: parameter when performing selector on main thread
- From: Jean-Daniel Dupas <email@hidden>
- Date: Tue, 12 Nov 2013 16:12:00 +0100
Le 12 nov. 2013 à 15:26, Graham Cox <email@hidden> a écrit :
> I’m just thinking about the use of -performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best way to think about the waitUntilDone parameter. The situation is updating a UI from another thread, using this to punt the update to the main thread (in fact the progress bar situation discussed earlier this week).
>
> I assume if I pass NO, the request is queued and processed once per event loop. If I pass YES, there is some sort of lock which sleeps my thread until the main thread completes the task.
>
> So passing NO, my worker thread can proceed as fast as it can, but the main thread could back up and end up lagging (and also queuing a lot of redundant updates, like a progress value where really only the latest matters). If I pass YES, my worker thread is going to get throttled by the main thread.
>
> Is this just one of those cases where you have to judge the best approach, or is there a better way to determine when to pass YES or NO?
>
> Currently, I generally pass NO, and my worker threads are not updating the progress too often anyway - I mod the count so that it only updates every 50 or 100 iterations. The UI seems to keep up fine. What do others do?
>
My rule is simply to never pass NO. In a world where async is the new standard, waiting for a thread to complete should really never be used.
Updating your UI more than 60 times per seconds is useless as the update will never be pushed to the screen, and the UI thread should be able to deal with 60 messages per seconds smoothly, so don't bother with premature optimisation, and keep it simple.
And even 60 times per seconds is probably too much anyway. Just make sure your worker thread does not push too much updates.
-- Jean-Daniel
_______________________________________________
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