How to Get the Current Queue Name in Swift 3

How to get the current queue name in swift 3

Now DispatchQueue has label property.

The label you assigned to the dispatch queue at creation time.

var label: String { get } 

---

It seems been existed from first, maybe not been exposed via public API.

macOS 10.10+

And please use this only to obtain human-readable labels. Not to identify each GCDQ.

If you want to check whether your code is running on certain GCDQ, you can use dispatchPrecondition(...) function.

Get current dispatch queue?

You do have the option of "dispatch_get_current_queue()", however the iOS 6.1 SDK defines this API with these disclaimers:

"Recommended for debugging and logging purposes only:"

and

"This function is deprecated and will be removed in a future release.".

Here's another related question with some alternatives you can consider if you want code that's future-proof.

How to check current thread in Swift 3?

Looks like it's simply Thread.isMainThread in Swift 3.

GCD obtaining queue name/label

How about dispatch_queue_get_label?

Log which queue/thread a method is running on

You can get the current thread with +[NSThread currentThread]. That could have a name property, but if you didn't set one don't rely on it.

Queues are trickier because there are different meanings of "queue". A queue could be an NSOperationQueue, and you can grab its name from +[NSOperationQueue currentQueue] (again, assuming you set it).

Then there are dispatch queues. You can get the current queue with dispatch_get_current_queue(), but be warned that this function will succeed even if called from code that isn't associated with a queue(!). In that case it returns the default background queue Queues are labeled, so you can call dispatch_queue_get_label() and if you created the queue with a label, you will get that.

So basically, yes you can get the queue or thread—with the proviso that all code has an associated dispatch queue even if it isn't code that was dispatched. You can also usually get meaningful names for these threads and queues, which is handy for debugging: but it's your responsibility to name them.

Check if on correct dispatch queue in Swift 3

Answering my own question:

Based on KFDoom's comments, I'm now using setSpecific and getSpecific.

This creates a key, sets it on the test queue, and later on, gets it again:

let testQueueLabel = "com.example.my-test-queue"
let testQueue = DispatchQueue(label: testQueueLabel, attributes: [])
let testQueueKey = DispatchSpecificKey<Void>()

testQueue.setSpecific(key: testQueueKey, value: ())

// ... later on, to test:

XCTAssertNotNil(DispatchQueue.getSpecific(key: testQueueKey), "callback should be called on specified queue")

Note that there's no value associated with the key (its type is Void), I'm only interested in the existence of the specific, not in it's value.

Important!

Make sure to keep a reference to the key, or cleanup after you're done using it. Otherwise a newly created key could use the same memory address, leading to weird behaviour. See: http://tom.lokhorst.eu/2018/02/leaky-abstractions-in-swift-with-dispatchqueue

How to create dispatch queue in Swift 3

Creating a concurrent queue

let concurrentQueue = DispatchQueue(label: "queuename", attributes: .concurrent)
concurrentQueue.sync {

}  

Create a serial queue

let serialQueue = DispatchQueue(label: "queuename")
serialQueue.sync { 

}

Get main queue asynchronously

DispatchQueue.main.async {

}

Get main queue synchronously

DispatchQueue.main.sync {

}

To get one of the background thread

DispatchQueue.global(qos: .background).async {

}

Xcode 8.2 beta 2:

To get one of the background thread

DispatchQueue.global(qos: .default).async {

}

DispatchQueue.global().async {
    // qos' default value is ´DispatchQoS.QoSClass.default`
}

If you want to learn about using these queues .See this answer

priority of Dispatch Queues in swift 3

You say:

The outcome shows that we ignore the asynchronous execution. ...

No, it just means that you didn't give the asynchronously dispatched code enough time to get started.

I know queue2 should be completed before queue1 since it's synchronous execution ...

First, queue2 might not complete before queue1. It just happens to. Make queue2 do something much slower (e.g. loop through a few thousand iterations rather than just five) and you'll see that queue1 can actually run concurrently with respect to what's on queue2. It just takes a few milliseconds to get going and the stuff on your very simple queue2 is finishing before the stuff on queue1 gets a chance to start.

Second, this behavior is not technically because it's synchronous execution. It's just that async takes a few milliseconds to get it's stuff running on some worker thread, whereas the synchronous call, because of optimizations that I won't bore you with, gets started more quickly.

but why we ignore the asynchronous execution ...

We don't "ignore" it. It just takes a few milliseconds to get started.

and what is the actual difference between async, sync and so-called main queue?

"Async" merely means that the current thread may carry on and not wait for the dispatched code to run on some other thread. "Sync" means that the current thread should wait for the dispatched code to finish.

The "main thread" is a different topic and simply refers to the primary thread that is created for driving your UI. In practice, the main thread is where most of your code runs, basically running everything except that which you manually dispatch to some background queue (or code that is dispatched there for you, e.g. URLSession completion handlers).

---

Related Topics