iOS URL Requests. Semaphore issues

Question

I'm entering the concurrency programming with some semaphore issues. My function first loads data from server, analyze received info and then, if necessary, makes second request to server.

I tried different ways to make it run, none of them did it well. My current code FOR ME seems to be correct, but on second request it just locks(maybe like a DeadLock) and the last log is "<__NSCFLocalDataTask: 0x7ff470c58c90>{ taskIdentifier: 2 } { suspended }"

Please, tell me what do I don't know. Maybe there is more elegant way to work with completions for these purposes?

Thank you in advance!

var users = [Int]()
let linkURL = URL.init(string: "https://bla bla")
let session = URLSession.shared()
let semaphore = DispatchSemaphore.init(value: 0)
let dataRequest = session.dataTask(with:linkURL!) { (data, response, error) in
    let json = JSON (data: data!)
    if (json["queue"]["numbers"].intValue>999) {
        for i in 0...999 {
            users.append(json["queue"]["values"][i].intValue)
        }
        for i in 1...lround(json["queue"]["numbers"].doubleValue/1000) {
            let session2 = URLSession.shared()
            let semaphore2 = DispatchSemaphore.init(value: 0)
            let linkURL = URL.init(string: "https://bla bla")
            let dataRequest2 = session2.dataTask(with:linkURL!) { (data, response, error) in
                let json = JSON (data: data!)
                print(i)
                semaphore2.signal()
            }
            dataRequest2.resume()
            semaphore2.wait(timeout: DispatchTime.distantFuture)
        }
    }
    semaphore.signal()
}
dataRequest.resume()
semaphore.wait(timeout: DispatchTime.distantFuture)

P.S. Why do I do it. Server returns limited count of data. To get more, I have to use offset.

Answer 1

This is deadlocking because you are waiting for a semaphore on the URLSession's delegateQueue. The default delegate queue is not the main queue, but it is a serial background queue (i.e. an OperationQueue with a maxConcurrentOperationCount of 1). So your code is waiting for a semaphore on the same serial queue that is supposed to be signaling the semaphore.

The tactical fix is to make sure you're not calling wait on the same serial queue that the session's completion handlers are running on. There are two obvious fixes:

1. Do not use shared session (whose delegateQueue is a serial queue), but rather instantiate your own URLSession and specify its delegateQueue to be a concurrent OperationQueue that you create:

   let queue = OperationQueue()
   queue.name = "com.domain.app.networkqueue"
   
   let configuration = URLSessionConfiguration.default()
   let session = URLSession(configuration: configuration, delegate: nil, delegateQueue: queue)
   

2. Alternatively, you can solve this by dispatching the code with the semaphore off to some other queue, e.g.

   let mainRequest = session.dataTask(with: mainUrl) { data, response, error in
       // ...
       DispatchQueue.global(attributes: .qosUserInitiated).async {
           let semaphore = DispatchSemaphore(value: 0)
   
           for i in 1 ... n {
               let childUrl = URL(string: "https://blabla/\(i)")!
               let childRequest = session.dataTask(with: childUrl) { data, response, error in
                   // ...
                   semaphore.signal()
               }
               childRequest.resume()
               _ = semaphore.wait(timeout: .distantFuture)
           }
       }
   }
   mainRequest.resume()
   

---

For the sake of completeness, I'll note that you probably shouldn't be using semaphores to issue these requests at all, because you'll end up paying a material performance penalty for issuing a series of consecutive requests (plus you're blocking a thread, which is generally discouraged).

The refactoring of this code to do that is a little more considerable. It basically entails issuing a series of concurrent requests, perhaps use "download" tasks rather than "data" tasks to minimize memory impact, and then when all of the requests are done, piece it all together as needed at the end (triggered by either a Operation "completion" operation or dispatch group notification).