What are the benefits to Apple's Dispatch Queue API designing for future functionality?

Question

What are the benefits of the design of the queue generation / retrieval APIs as opposed to having helper functions that simply pass along the default value at the time they introduced the API?

Examples:

dispatch_queue_global_t dispatch_get_global_queue(intptr_t identifier, uintptr_t flags)
dispatch_queue_t dispatch_queue_create(const char *label, dispatch_queue_attr_t attr)

The necessitation to send magic values such as NULL and 0 as parameters seems a bit verbose and was curious if there are any benefits or the motivation for designing them in this way since it seems that introducing the new methods would be a non-breaking change.

512

Posted by

nmock

Reply

Add a Comment

Answer 1

That said, any benefit to dropping down to C rather than exposing the dispatch queues via Objective-C instead?

For you? Probably not. In general? It’s not uncommon for folks to write programs that can’t use Objective-C, and those folks rely on the C API.

Keep in mind that there is an Objective-C API that’s the conceptual twin of Dispatch queues, namely NSOperationQueue. As I like to say, NSOperationQueue is to dispatch_queue_t as NSObject is to malloc. There are good reasons for Objective-C code to call malloc, but most of the time it’s better to subclass NSObject and then create an instance of that subclass. Similarly, there are good reasons for Objective-C code to use a Dispatch queue, but most of the time an NSOperationQueue is a better choice.

Having said that, I’m definitely in a the minority here. There are lots of folks who are much more enthusiastic about Dispatch than I am.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 2

The second parameter to dispatch_queue_create() is used for DISPATCH_QUEUE_SERIAL or DISPATCH_QUEUE_CONCURRENT. As for dispatch_get_global_queue(), who knows? It could have been used internally or they thought they would need it but never did. ObjC doesn't support default values like Swift does, so a lot of old code requires extra parameters.

Posted by

EricS

Add a Comment

Answer 3

ObjC doesn't support default values like Swift does, so a lot of old code requires extra parameters.

Right, although this is more of a C thing than an Objective-C thing. In Objective-C you can simulate default parameters by introducing new methods. For example, in NSString you have:

- (instancetype)initWithFormat:(NSString *)format, ...
- (instancetype)initWithFormat:(NSString *)format locale:(nullable id)locale, ...

where the first is equivalent to the second with a default locale parameter.

However, when you’re working in C you can’t do that and the alternative, adding new APIs with slight name variants, is kinda ugly. For example, sqlite3_open, sqlite3_open16, and sqlite3_open_v2. Or, just so I’m not picking on one specific API, there’s connect and connectx in BSD Sockets.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 4

I suppose you're right since C doesn't support function overloading in the traditional sense. That said, any benefit to dropping down to C rather than exposing the dispatch queues via Objective-C instead? For example, NSNotification exposes the default notification as a class method, why not expose the queues in a similar manner? It seems that these are methods are used in conjunction in the context of Objective C for the most part.

I get I can simply write my own wrappers, but just curious from a deeper perspective as to possible motivations behind their architecture. Is there a huge performance hit or something I'm missing?

Posted by

nmock

Add a Comment

Answer 5

That said, any benefit to dropping down to C rather than exposing the dispatch queues via Objective-C instead?

For you? Probably not. In general? It’s not uncommon for folks to write programs that can’t use Objective-C, and those folks rely on the C API.

Keep in mind that there is an Objective-C API that’s the conceptual twin of Dispatch queues, namely NSOperationQueue. As I like to say, NSOperationQueue is to dispatch_queue_t as NSObject is to malloc. There are good reasons for Objective-C code to call malloc, but most of the time it’s better to subclass NSObject and then create an instance of that subclass. Similarly, there are good reasons for Objective-C code to use a Dispatch queue, but most of the time an NSOperationQueue is a better choice.

Having said that, I’m definitely in a the minority here. There are lots of folks who are much more enthusiastic about Dispatch than I am.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 6

Oh, I should finish this off by saying that I’m very enthusiastic about Swift’s new concurrency features. Over the years we’ve learnt a lot from NSOperation, Dispatch, Combine, and so on, and Swift concurrency was designed with all of that experience in mind.

WWDC has a lot of great Swift concurrency talks this year, but the one I’m most looking forward to is WWDC 2021 Session 10254 Swift concurrency: Behind the scenes.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

What are the benefits to Apple's Dispatch Queue API designing for future functionality?

Accepted Reply

Replies