issue with dispatch_async and async request

Question

So the first question is how does dispatch_async determines which thread to use? just picks it randomly? I need to do some parsing and core data stuff, so I don't want to block UI thread and use dispatch_async, but after that I send a NSURLRequest to fetch some more data and the callback is never invoked (probably because the thread is already dead).

So what's a good way of making it? And I can not use

sendAsynchronousRequest:queue:completionHandler:

because the deployment OS is 4. for now I just send request inside

dispatch_async(dispatch_get_main_queue(), ^{
});

which is inside dispatch_async(myQueue) block which does all the parsing and saving to core data. But it does not seem right to me, I mean there should be a way to use dispatch_async and tell it not kill the tread, right? Because using sync requests is not an option.

score 12 · Accepted Answer · edited May 23 '17 at 11:52

So the first question is how does dispatch_async determines which thread to use?

You should not be thinking of threads when using GCD. That's all handled behind the scenes for you. You think in queues which is what you pass to dispatch_async along with the block to execute. A GCD queue does sort of map to a thread, but you don't need to worry about what is going on behind the scenes - GCD will handle all that for you.

As for your code which I assume looks similar to this:

dispatch_async(myQueue, ^{
    // Do some stuff off the main queue

    dispatch_async(dispatch_get_main_queue(), ^{ 
        // Do something with the UI
    });
});

There is nothing wrong with that at all. You do not need to worry that the thread that the block you sent to myQueue runs on, might be terminated. The queue will stay around until the block as finished running. The fact that you dispatch onto the main queue within the original dispatch is fine - the work on the main queue will happily run perfectly fine.

I think you're also asking why when using NSURLRequest within an async dispatch you are seeing it not ever invoke the callback. That will be because it's tightly coupled to the current run loop and if you're currently on a background thread (which your myQueue will be running on) then that run loop won't be run again until another block is put on the queue. So your callback never runs.

I encourage you to go and read more about GCD and what async vs sync actually means as I feel that you are possibly not fully understanding it yet. I answered a similar question about that here.

So then my question is if I create really a lot of dispatch_async-s with a sync network request inside will I run out of threads? — dariaa, Mar 27 '12 at 10:25
`dispatch_async` != new thread. A new *queue* might mean a new thread, it might not. Repeat after me: "I must not worry about threads, GCD will handle it for me". :-). — mattjgalloway, Mar 27 '12 at 10:27
So basically, if you're dispatching async onto the same queue, these will all run one after the other (unless it's a parallel queue). See the post I linked to at the end of my answer for more on that. — mattjgalloway, Mar 27 '12 at 10:27
so, just to be sure, calling a sync request inside dispatch_async is totally ok? (except for the fact that it can not be cancelled) — dariaa, Mar 27 '12 at 10:59
It's fine as long as you're not dispatching onto the same queue as the `dispatch_async`, which should be fairly obvious. Synchronous means the call to `dispatch_sync` won't return until the block you dispatch has finished, which can't run until the outer block has returned = deadlock. — mattjgalloway, Mar 27 '12 at 11:30

Ashley Mills · Answer 2 · 2012-03-27T09:42:20.273

When you use sendAsynchronousRequest:... within a block, the block will terminate before the asynchronous request callback is fired.

As you're already in a background thread, how about using a synchronous method within that thread to get your data - +[NSURLRequest sendSynchronousRequest:returningResponse:error:] , or even simpler, +[NSData dataWithContentsOfURL:].

You can call these within the block running on a background thread, and the block won't progress until the call is complete. You can then update your UI by calling back to the main queue:

dispatch_async(yourQueue, ^{
    // Do some stuff

    NSData * fetchedData = [NSData dataWithContentsOfURL: someURL];

    // Do some more stuff with the data

    dispatch_async(dispatch_get_main_queue(), ^{
       // Do some stuff on the main queue
    }
});

But what I'm worried about is (from the GCD reference) "function does not return until the block has finished. Calling this function and targeting the current queue results in deadlock." and this code will be executed a bunch of times. I receive a response with say 20 ids and I then send a request for every one of them, so what if the server is not available for instance? the thread will be blocked.. I was used to thinking that using any sync request is not a good idea — dariaa, Mar 27 '12 at 09:55

score 0 · Answer 3 · answered Nov 08 '13 at 07:14

You are right, the problem is that the thread is dead, because the NSURLConnection won't keep it alive for you during its lifetime. The connection will be discarded when it returns. You can keep the thread alive explicitly with some dark magic ;) and release the thread when you are done. In this case by setting _isFinishedLoading to true on success or on error.

So in this case it is not true to not care about threads when using blocks, because NSURLConnection is not really compatible. Blocks however are extremely useful, since the framework chooses the best thread for you depending on the underlying hardware and available ressources.

NSURLConnection* connection = [NSURLConnection connectionWithRequest:urlRequest delegate:self];
[connection start];
NSRunLoop *runloop = [NSRunLoop currentRunLoop];
_isFinishedLoading = NO;
while (!_isFinishedLoading)
{
    [runloop runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.1]];
}

issue with dispatch_async and async request

3 Answers3