I was having problems modifying a view inside a thread. I tried to add a subview but it took around 6 or more seconds to display. I finally got it working, but I don&#39;t know how exactly. So I was wondering why it worked and what&#39;s the difference between the following methods:

1. This worked -added the view instantly:
```
dispatch_async(dispatch_get_main_queue(), ^{
    //some UI methods ej
    [view addSubview: otherView];
}
```
2. This took around 6 or more seconds to display:
```
[viewController performSelectorOnMainThread:@selector(methodThatAddsSubview:) withObject:otherView
    waitUntilDone:NO];
```

3. `NSNotification` methods -  took also around 6 seconds to display the observer was in the viewController I wanted to modify paired to a method to add a subview.
```
[[NSNotificationCenter defaultCenter] postNotificationName:
 @&quot;notification-identifier&quot; object:object];
```

For reference these were called inside this `CompletionHandler` of the class `ACAccountStore`.

    accountStore requestAccessToAccountsWithType:accountType withCompletionHandler:^(BOOL granted, NSError *error) {
        if(granted) {
            // my methods were here
        }
    }

What&#39;s the difference between performSelectorOnMainThread: and dispatch_async() on main queue?

 Okay, so I found out about the new [Swifty Dispatch API][1] in Xcode 8. I&#39;m having fun using `DispatchQueue.main.async`, and I&#39;ve been browsing around the `Dispatch` module in Xcode to find all the new APIs.
 
  [1]: https://stackoverflow.com/q/37801370/957768

 But I also use `dispatch_once` to make sure that things like singleton creation and one-time setup don&#39;t get executed more than once (even in a multithreaded environment)... and `dispatch_once` is nowhere to be found in the new Dispatch module?


    static var token: dispatch_once_t = 0
    func whatDoYouHear() {
        print(&quot;All of this has happened before, and all of it will happen again.&quot;)
        dispatch_once(&amp;token) {
            print(&quot;Except this part.&quot;)
        }
    }



Whither dispatch_once in Swift 3?

Bear with me, this is going to take some explaining. I have a function that looks like the one below.

Context: &quot;aProject&quot; is a Core Data entity named LPProject with an array named &#39;memberFiles&#39; that contains instances of another Core Data entity called LPFile. Each LPFile represents a file on disk and what we want to do is open each of those files and parse its text, looking for @import statements that point to OTHER files. If we find @import statements, we want to locate the file they point to and then &#39;link&#39; that file to this one by adding a relationship to the core data entity that represents the first file. Since all of that can take some time on large files, we&#39;ll do it off the main thread using GCD.



    - (void) establishImportLinksForFilesInProject:(LPProject *)aProject {
        dispatch_queue_t taskQ = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
         for (LPFile *fileToCheck in aProject.memberFiles) {
             if (//Some condition is met) {
                dispatch_async(taskQ, ^{
                    // Here, we do the scanning for @import statements. 
                    // When we find a valid one, we put the whole path to the imported file into an array called &#39;verifiedImports&#39;. 
                
                    // go back to the main thread and update the model (Core Data is not thread-safe.)
                    dispatch_sync(dispatch_get_main_queue(), ^{
                                
                        NSLog(@&quot;Got to main thread.&quot;);
                                
                        for (NSString *import in verifiedImports) {  
                                // Add the relationship to Core Data LPFile entity.
                        }
                    });//end block
                });//end block
            }
        }
    }



Now, here&#39;s where things get weird:

This code works, but I&#39;m seeing an odd problem. If I run it on an LPProject that has a few files (about 20), it runs perfectly. However, if I run it on an LPProject that has more files (say, 60-70), it does **NOT** run correctly. We never get back to the main thread, the `NSLog(@&quot;got to main thread&quot;);` never appears and the app hangs. BUT, (and this is where things get REALLY weird) --- if I run the code on the small project FIRST and THEN run it on the large project, everything works perfectly. It&#39;s ONLY when I run the code on the large project first that the trouble shows up.

And here&#39;s the kicker, if I change the second dispatch line to this:

    dispatch_async(dispatch_get_main_queue(), ^{

(That is, use `async` instead of `sync` to dispatch the block to the main queue), everything works all the time. Perfectly. Regardless of the number of files in a project! 

I&#39;m at a loss to explain this behavior. Any help or tips on what to test next would be appreciated. 

dispatch_sync vs. dispatch_async on main queue

I am struggling to understand the key differences between [DispatchSourceTimer][1], [Timer][2] and [asyncAfter][3] (**in my case for scheduling a task that needs to be ran every X seconds, although understanding the differences in timers can be useful to**) (Or is there another (more efficient) scheduling mechanism in Swift besides the listed timers?).

A `Timer` needs an active run loop on the current queue it was started on. A `DispatchSourceTimer` does not need that. A `Timer` keeps the CPU from going into the idle state. Does this apply to `DispatchSourceTimer`/`asyncAfter` as well?

In what situation a `Timer` is preferred over a `DispatchSourceTimer`/`asyncAfter`? And of course the difference between all of them?

I want to schedule work every 15 seconds in my application on a private queue. This means I have to use `DispatchSourceTimer` because I am on a queue that is not the main thread (or add a runloop to the queue and use `Timer`). However, I do not see any benefit of even using a `Timer` in the first place. Maybe there is another operation that I can use that schedule work every X seconds on a private queue that is more efficient than a `DispatchSourceTimer`, but I did not came across a better solution.

Is a `DispatchSourceTimer` more efficient than a `Timer`? Or should I go on a self-calling method with `asyncAfter`?

This is the code to create the timers.

**asyncAfter**
        
    DispatchQueue.global().asyncAfter(deadline: .now() + .seconds(2)) {
        // Code
    }

**Timer**

    Timer.scheduledTimer(withTimeInterval: 1, repeats: false) { (_) in
        // Code
    }

**DispatchSourceTimer**

    let timer = DispatchSource.makeTimerSource()
        
    timer.schedule(deadline: .now() + .seconds(1))
        
    timer.setEventHandler {
        // Code
    }
        
    timer.activate()

Whats are the cons and pros of all the timers? When should I use one above the other? What timer way is the most efficient? I came up with the following:

Timer
-----

Pros:

 - Can be invalidated
 - No reference needed
 - Can be stopped while it is scheduled.

Cons:

 - Prevents CPU to go idle
 - Needs to be run on a queue with a run loop (else nothing happens, even no assertion trigger...)

DispatchSourceTimer
-------------------
Pros:

 - Can be cancelled
 - No run loop needed

Cons:

 - Needs a strong reference else it gets deallocated instantly

asyncAfter
----------
Pros:
 - No run loop needed

Cons:
 - Can not be cancelled (I think)

Are there even more timers? Why are there so many timers? I expected some real difference across all the different timers, but I couldn&#39;t find them. 

Alot of questions here as you can read. The main question is: **what timers are available and what timers should I use in what case and why?**

  [1]: https://developer.apple.com/documentation/dispatch/dispatchsourcetimer
  [2]: https://developer.apple.com/documentation/foundation/timer
  [3]: https://developer.apple.com/documentation/dispatch/dispatchqueue/2300020-asyncafter

Difference between DispatchSourceTimer, Timer and asyncAfter?

I learned iOS programming thanks to Stanford&#39;s CS193p course (on iTunes U) as well as the iOS programming book from Big Nerd Ranch.  In both of those, they recommend using `dispatch_async()`, `dispatch_get_main_queue()`, etc. to handle threading and concurrent operations.  However, at WWDC 2012&#39;s session on building concurrent UI, the speaker recommended the use of `NSOperationQueue`.

What are the differences between `dispatch_*()` and `NSOperationQueue`, and is there any reason (technical, performance, stylistic, or otherwise) that I should use one over the other?  Is `NSOperationQueue` just an Objective-C wrapper around `dispatch_async`, or is there more to it than that?


(iOS) dispatch_async() vs. NSOperationQueue

I have a callback which might come from any thread. When I get this callback, then I would like to perform a certain task on the main thread.

Do I need to check whether I already am on the main thread - or is there any penalty by not performing this check befora calling the code below?

    dispatch_async(dispatch_get_main_queue(), ^{
       // do work here
    });



GCD to perform task in main thread

I have lots of code in Swift 2.x (or even 1.x) projects that looks like this:

    // Move to a background thread to do some long running work
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)) {
        let image = self.loadOrGenerateAnImage()
        // Bounce back to the main thread to update the UI
        dispatch_async(dispatch_get_main_queue()) {
            self.imageView.image = image
        }
    }

Or stuff like this to delay execution:

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, Int64(0.5 * Double(NSEC_PER_SEC))), dispatch_get_main_queue()) {
        print(&quot;test&quot;)
    }

Or any of all kinds of other uses of the Grand Central Dispatch API...

Now that I&#39;ve opened my project in Xcode 8 (beta) for Swift 3, I get all kinds of errors. Some of them offer to fix my code, but not all of the fixes produce working code. What do I do about this?



How do I dispatch_sync, dispatch_async, dispatch_after, etc in Swift 3, Swift 4, and beyond?

In my app I have a function that makes an NSRURLSession and sends out an NSURLRequest using
  
    sesh.dataTaskWithRequest(req, completionHandler: {(data, response, error)

In the completion block for this task, I need to do some computation that adds a UIImage to the calling viewcontroller. I have a func called

    func displayQRCode(receiveAddr, withAmountInBTC:amountBTC)

that does the UIImage-adding computation. If I try to run the view-adding code inside of the completion block, Xcode throws an error saying that I can&#39;t use the layout engine while in a background process. So I found some code on SO that tries to queue a method on the main thread:

    let time = dispatch_time(DISPATCH_TIME_NOW, Int64(0.0 * Double(NSEC_PER_MSEC)))
    
    dispatch_after(time, dispatch_get_main_queue(), {
        let returned = UIApplication.sharedApplication().sendAction(&quot;displayQRCode:&quot;, to: self.delegate, from: self, forEvent: nil)
    })

However, I don&#39;t know how to add the parameters &quot;receiveAddr&quot; and &quot;amountBTC&quot; to this function call. How would I do this, or can someone suggest an optimal way for adding a method call to the application&#39;s main queue?

In Swift how to call method with parameters on GCD main thread?

When using GCD, we want to wait until two async blocks are executed and done before moving on to the next steps of execution. What is the best way to do that?

We tried the following, but it doesn&#39;t seem to work:

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^ {
        // block1
    });


    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^ {
        // block2
    });

    // wait until both the block1 and block2 are done before start block3
    // how to do that?

    dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^ {
        // block3
    });


Waiting until two async blocks are executed before starting another block

I would like a for in loop to send off a bunch of network requests to firebase, then pass the data to a new view controller once the the method finishes executing. Here is my code:

    var datesArray = [String: AnyObject]()
           
    for key in locationsArray {       
        let ref = Firebase(url: &quot;http://myfirebase.com/&quot; + &quot;\(key.0)&quot;)
        ref.observeSingleEventOfType(.Value, withBlock: { snapshot in
                
            datesArray[&quot;\(key.0)&quot;] = snapshot.value
        })
    }
    // Segue to new view controller here and pass datesArray once it is complete 

I have a couple concerns. First, how do I wait until the for loop is finished and all the network requests are complete? I can&#39;t modify the observeSingleEventOfType function, it is part of the firebase SDK. Also, will I create some sort of race condition by trying to access the datesArray from different iterations of the for loop (hope that makes sense)? I&#39;ve been reading about GCD and NSOperation but I&#39;m a bit lost as this is the first app I&#39;ve built. 

Note: Locations array is an array containing the keys I need to access in firebase. Also, it&#39;s important that the network requests are fired off asynchronously. I just want to wait until ALL the asynchronous requests complete before I pass the datesArray to the next view controller.

Wait until swift for loop with asynchronous network requests finishes executing

I am testing some code that does asynchronous processing using Grand Central Dispatch. The testing code looks like this:

    [object runSomeLongOperationAndDo:^{
        STAssert…
    }];

The tests have to wait for the operation to finish. My current solution looks like this:

    __block BOOL finished = NO;
    [object runSomeLongOperationAndDo:^{
        STAssert…
        finished = YES;
    }];
    while (!finished);

Which looks a bit crude, do you know a better way? I could expose the queue and then block by calling `dispatch_sync`:

    [object runSomeLongOperationAndDo:^{
        STAssert…
    }];
    dispatch_sync(object.queue, ^{});

…but that’s maybe exposing too much on the `object`.

How do I wait for an asynchronously dispatched block to finish?

Is there a way to call a block with a primitive parameter after a delay, like using `performSelector:withObject:afterDelay:` but with an argument like `int`/`double`/`float`?


How do you trigger a block after a delay, like -performSelector:withObject:afterDelay:?

I have been using with success, grand central dispatch in my apps, but I was wondering what is the real advantage of using something like this:

    dispatch_async(dispatch_get_main_queue(), ^{ ... do stuff

or even

    dispatch_sync(dispatch_get_main_queue(), ^{ ... do stuff

I mean, in both cases you are firing a block to be executed on the main thread, exactly where the app runs and this will not help to reduce the load. In the first case you don&#39;t have any control when the block will run. I have seen cases of blocks being executed half a second after you fire them. The second case, it is similar to

    [self doStuff];

right?

I wonder what do you guys think.




iPhone - Grand Central Dispatch main thread

  I&#39;m struggling to fully understand the concurrent and serial queues in GCD. I have some issues and hoping someone can answer me clearly and at the point.

1. I&#39;m reading that serial queues are created and used in order to execute tasks one after the other. However, what happens if:
   - I create a serial queue
   - I use `dispatch_async` (on the serial queue I just created) three times to dispatch three blocks A,B,C

  Will the three blocks be executed:
  - in order A,B,C because the queue is serial

     OR
  - concurrently (in the same time on parralel threads) because I used ASYNC dispatch


2. I&#39;m reading that I can use `dispatch_sync` on concurrent queues in order to execute blocks one after the other. In that case, WHY do serial queues even exist, since I can always use a concurrent queue where I can dispatch SYNCHRONOUSLY as many blocks as I want?


 Thanks for any good explanation!

Concurrent vs serial queues in GCD

I&#39;ve created a serial queue like this:

        dispatch_queue_t _serialQueue = dispatch_queue_create(&quot;com.example.name&quot;, DISPATCH_QUEUE_SERIAL);

What&#39;s the difference between `dispatch_async` called like this

     dispatch_async(_serialQueue, ^{ /* TASK 1 */ });
     dispatch_async(_serialQueue, ^{ /* TASK 2 */ });

And `dispatch_sync` called like this on this serial queue?

     dispatch_sync(_serialQueue, ^{ /* TASK 1 */ });
     dispatch_sync(_serialQueue, ^{ /* TASK 2 */ });

My understanding is that, regardless of which dispatch method is used, `TASK 1` will be executed and completed before `TASK 2`, correct?

Difference between dispatch_async and dispatch_sync on serial queue?

How could I make my code wait until the task in DispatchQueue finishes? Does it need any CompletionHandler or something?

    func myFunction() {
        var a: Int?
    
        DispatchQueue.main.async {
            var b: Int = 3
            a = b
        }
    
        // wait until the task finishes, then print 
    
        print(a) // - this will contain nil, of course, because it
                 // will execute before the code above

    }

I&#39;m using Xcode 8.2 and writing in Swift 3.

Waiting until the task finishes

I&#39;ve gone through the [iBook][1] from Apple, and couldn&#39;t find any definition of it:

Can someone explain the structure of `dispatch_after`?

    dispatch_after(&lt;#when: dispatch_time_t#&gt;, &lt;#queue: dispatch_queue_t?#&gt;, &lt;#block: dispatch_block_t?#&gt;)

  [1]: https://web.archive.org/web/20140719155151/https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/BuildingCocoaApps.pdf

dispatch_after - GCD in Swift?

I have a method that accepts a block and a completion block. The first block should run in the background, while the completion block should run in whatever queue the method was called.

For the latter I always used `dispatch_get_current_queue()`, but it seems like it&#39;s deprecated in iOS 6 or higher. What should I use instead?

Alternatives to dispatch_get_current_queue() for completion blocks in iOS 6?

I&#39;m learning about concurrent programming for iOS. So far I&#39;ve read about [`NSOperation`/`NSOperationQueue`][1] and [`GCD`][2]. **What are the reasons for using `NSOperationQueue` over `GCD` and vice versa?**

Sounds like both `GCD` and `NSOperationQueue` abstract away the explicit creation of `NSThreads` from the user. However the relationship between the two approaches isn&#39;t clear to me so any feedback to appreciated!


  [1]: http://www.cimgf.com/2008/02/16/cocoa-tutorial-nsoperation-and-nsoperationqueue/
  [2]: https://en.wikipedia.org/wiki/Grand_Central_Dispatch

NSOperation vs Grand Central Dispatch

I&#39;m reading apple&#39;s documentation about &quot;Memory Management for Dispatch Queues&quot;:

&gt; Even if you implement a garbage-collected application, you must still retain and release your dispatch queues and other dispatch objects. Grand Central Dispatch does not support the garbage collection model for reclaiming memory.

I know that ARC is not a garbage collector but I&#39;d like to be sure that I don&#39;t need to dispatch_retain and dispatch_release my dispatch_queue_t

Does ARC support dispatch queues?

In Swift 2, I was able to use `dispatch_after` to delay an action using grand central dispatch:

    var dispatchTime: dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW, Int64(0.1 * Double(NSEC_PER_SEC))) 
    dispatch_after(dispatchTime, dispatch_get_main_queue(), { 
        // your function here 
    })

But this no longer seems to compile since Swift 3. What is the preferred way to write this in modern Swift?

How do I write dispatch_after GCD in Swift 3, 4, and 5?

What is the new syntax for `dispatch_once` in Swift after the changes made in language version 3? The old version was as follows.

    var token: dispatch_once_t = 0
    func test() {
        dispatch_once(&amp;token) {
        }
    }

These [are the changes to libdispatch][1] that were made. 


  [1]: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

dispatch_once after the Swift 3 GCD API changes

In Swift 2, I was able to create queue with the following code:



    let concurrentQueue = dispatch_queue_create(&quot;com.swift3.imageQueue&quot;, DISPATCH_QUEUE_CONCURRENT)

But this doesn&#39;t compile in Swift 3.  

What is the preferred way to write this in Swift 3?

How to create dispatch queue in Swift 3

Can anyone explain with really clear use cases what the purpose of `dispatch_sync` in `GCD` is for? I can&#39;t understand where and why I would have to use this.


Thanks!

using dispatch_sync in Grand Central Dispatch

 1. What are the differences between Operation Queue and Dispatch Queue?
 2. Under what circumstances will it be more appropriate to use each?

Operation Queue vs Dispatch Queue for iOS Application

Normally, if you spawn a background thread or run an NSOperation on an NSOperationQueue you need to create an NSAutoreleasePool for that thread or operation because none exists by default.  

Does the same rule apply to a block that is placed within a Grand Central Dispatch queue and will be run on a non-main thread?  That is, do you need to create an NSAutoreleasePool within each block you dispatch to anything other than the main queue?

In my limited testing, I don&#39;t see the console warnings for autoreleased objects that you normally see with background threads or NSOperations.  However, I can&#39;t seem to find definitive documentation on this, so I was wondering if someone could point out where this is stated.


Do you need to create an NSAutoreleasePool within a block in GCD?

I was going through the tutorial :
[https://www.raywenderlich.com/148513/grand-central-dispatch-tutorial-swift-3-part-1][1]

And came across the definition of QoS class **User-interactive**.
Its mentioned there that this should run on main thread. 
So, my question is then what is the difference between the 

    DispatchQueue.global(qos: .userInteractive).async{} 
and 
    
    DispatchQueue.main.async{}
 
Thanks!!

  [1]: https://www.raywenderlich.com/148513/grand-central-dispatch-tutorial-swift-3-part-1

Is DispatchQueue.global(qos: .userInteractive).async same as DispatchQueue.main.async

If I have a serial queue, how can I, from the main thread, tell it to immediately stop execution and cancel all of its tasks?

How to stop the execution of tasks in a dispatch queue?

If you can target iOS 4.0 or above

Using GCD, is it the best way to create singleton in Objective-C (thread safe)?

    + (instancetype)sharedInstance
    {
        static dispatch_once_t once;
        static id sharedInstance;
        dispatch_once(&amp;once, ^{
            sharedInstance = [[self alloc] init];
        });
        return sharedInstance;
    }


Create singleton using GCD&#39;s dispatch_once in Objective-C

Among some other ways, there are these two ways to get queues in `GCD`:

    dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    
    dispatch_get_main_queue();

If I&#39;m not completely wrong, the &quot;main queue&quot; is executing on the main thread and is good for &quot;callback&quot; blocks which execute UI work.

Does this mean a &quot;global queue&quot; is one that runs on a background thread?

What&#39;s the difference between the &quot;global queue&quot; and the &quot;main queue&quot; in GCD?

I need to dispatch a block on the main queue, synchronously. I don’t know if I’m currently running on the main thread or no. The naive solution looks like this:

    dispatch_sync(dispatch_get_main_queue(), block);

But if I’m currently inside of a block running on the main queue, this call creates a deadlock. (The synchronous dispatch waits for the block to finish, but the block does not even start running, since we are waiting for the current one to finish.)

The obvious next step is to check for the current queue:

    if (dispatch_get_current_queue() == dispatch_get_main_queue()) {
        block();
    } else {
        dispatch_sync(dispatch_get_main_queue(), block);
    }

This works, but it’s ugly. Before I at least hide it behind some custom function, isn’t there a better solution for this problem? I stress that I can’t afford to dispatch the block asynchronously – the app is in a situation where the asynchronously dispatched block would get executed “too late”.

How to dispatch on main queue synchronously without a deadlock?

I ran into a scenario where I had a delegate callback which could occur on either the main thread or another thread, and I wouldn&#39;t know which until runtime (using `StoreKit.framework`).

I also had UI code that I needed to update in that callback which needed to happen before the function executed, so my initial thought was to have a function like this:

    -(void) someDelegateCallback:(id) sender
    {
        dispatch_sync(dispatch_get_main_queue(), ^{
            // ui update code here
        });

        // code here that depends upon the UI getting updated
    }

That works great, when it is executed on the background thread. However, when executed on the main thread, the program comes to a deadlock.

That alone seems interesting to me, if I read the docs for `dispatch_sync` right, then I would expect it to just execute the block outright, not worrying about scheduling it into the runloop, as said [here](https://developer.apple.com/library/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/c/func/dispatch_sync):

 &gt; As an optimization, this function invokes the block on the current thread when possible.

But, that&#39;s not too big of a deal, it simply means a bit more typing, which lead me to this approach:

    -(void) someDelegateCallBack:(id) sender
    {
        dispatch_block_t onMain = ^{
            // update UI code here
        };

        if (dispatch_get_current_queue() == dispatch_get_main_queue())
           onMain();
        else
           dispatch_sync(dispatch_get_main_queue(), onMain);
    }

However, this seems a bit backwards. Was this a bug in the making of GCD, or is there something that I am missing in the docs?

Why can&#39;t we use a dispatch_sync on the current queue?

I have a method which should support being called from any queue, and should expect to.

It runs some code in a background thread itself, and then uses `dispatch_get_main_queue` when it returns a value to its block argument.

I don&#39;t want it to force it onto the main queue if it wasn&#39;t when it entered the method. Is there a way to get a pointer to the current dispatch queue?

Get current dispatch queue?

For the longest time I thought asynchronous was synonymous to running something on a background thread, while synchronous meant on the main thread (blocking UI updates and interactions). I understand that not running on the main thread for expensive actions is because it doesn&#39;t allow UI actions to occur as the main thread is occupied, but why is synchronous troublesome?

However, it&#39;s since came to my attention that you can make asynchronous calls on the main thread, and synchronous calls on background threads.

I always hear people saying not to use expensive calls synchronously or on the main thread, as it will block the UI for the user. Are these two separate issues I should be making sure I don&#39;t do? What are the differences?

All Grand Central-Dispatch Solutions on Gang of Coders

Total of 34 Grand Central-Dispatch Solutions

What's the difference between performSelectorOnMainThread: and dispatch_async() on main queue?