On Nov 12, 2013, at 06:26 , Graham Cox <graham....@bigpond.com> wrote:
> I’m just thinking about the use of > -performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best > way to think about the waitUntilDone parameter. Perhaps the question is why you’re using ‘performSelector’ for this at all, other than historical inertia. In the past, the best solution would probably have been to specify NO for ‘waitUntilDone’, but also to immediately precede this with an invocation of ‘cancelPreviousPerform…’ to stop multiple performs from getting queued up. (That still works, of course.) Now, it would be more natural to use GCD for this — dispatch a block onto the main queue, with a suitable [thread-safe] test to skip queuing anything when there’s still a block queued from the last time. When you use a block for this, you don’t have to worry about passing any parameters from the background thread to the main thread (if there are any), because they can be captured in the block instead. So, all you really need is a shared BOOL variable to control the queuing behavior. In the background thread, if the variable is NO, set it to YES and queue a block. In the queued block (running on the main thread), simply set the variable to NO and start a UI update. Of course, both those actions involving the variable (test/set in the background thread, clear in the main thread) need to be done atomically, and for that you can use a GCD semaphore — bracket the sensitive code with a semaphore wait/release pair. This is one of those things that’s almost harder to describe in words than it is to do in code. _______________________________________________ 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
