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: Jens Alfke <email@hidden>
- Date: Tue, 12 Nov 2013 07:51:24 -0800
On Nov 12, 2013, at 6:26 AM, Graham Cox <email@hidden> wrote:
> 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.
Right.
> 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.
In my experience you almost never want to use YES. The only reason would be if your background thread needs to get some kind of response from the main thread (like it’s asking it for a data value and can’t proceed until it gets it.) Otherwise you’re just needlessly slowing down the background thread, and in the worst case inviting deadlocks.
If you just perform a really lightweight update from the background thread (e.g. just calling -setNeedsDisplay on some progress-indicator view) you shouldn’t have trouble with the main thread falling behind.
Another option is to have the main thread poll the progress of the operation instead of being notified. That way you can decide explicitly how often you want to update the progress indicator.
—Jens
_______________________________________________
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