Perform on Next Run Loop: What's Wrong With GCD? Perform on Next Run Loop: What's Wrong With GCD? ios ios

Perform on Next Run Loop: What's Wrong With GCD?


I believe the answer is found here in a discussion of the main dispatch queue:

This queue works with the application’s run loop (if one is present) to interleave the execution of queued tasks with the execution of other event sources attached to the run loop.

In other words, the main dispatch queue sets up a secondary queue (alongside the standard event queue provided by UIApplicationMain() for handling blocks submitted to the main queue. When blocks are present in the queue, the run loop will alternate dequeuing tasks from the main event queue and the dispatch queue. On the other hand, the reference for the delay parameter of -performSelector:withObject:afterDelay: notes that:

Specifying a delay of 0 does not necessarily cause the selector to be performed immediately. The selector is still queued on the thread’s run loop and performed as soon as possible.

Thus, when you use perform selector, the operation is queued at the end of the main event queue, and will not be performed until after everything in front of it in the queue (presumably including the code to unhighlight the UIButton) has been processed. When you use the main dispatch queue, however, it adds the block into the secondary queue which then likely gets processed immediately (i.e., on the next run loop) assuming there are no other blocks in the main queue. In this case, the code to unhighlight the button is still sitting in the main event queue while the run loop processes the event from the secondary block queue.


I think this will hit your point:

[[NSOperationQueue mainQueue] addOperationWithBlock:^{     //bla bla bla}];


matomo