Thread Explosion for the Global Queues and NSOperationQueues

AFAIK, thread explosion can't occur on serial queues, because there can never be a need for more than one thread per serial queue. However, having hundreds of serial queues doesn't seem like a great idea.

>> Can thread explosion happen to the global queues?

Oh, yes.

I think the point is to structure your code in terms of your work units (closures), however small they are, generally queuing other work units as they complete. This is in contrast to generating all of the work units initially, and expecting the system to schedule them rationally. The latter is not a stupid concept, but the system just doesn't work that way.

The main thing to worry about is doing work that may require that the thread waits. That includes synchronous I/O operations, taking locks, or submitting work synchronously to a queue (i.e. dispatch_sync()) that may be busy.

For I/O, try to use dispatch I/O. For locks or dispatch_sync(), try to restructure your code to be asynchronous with "continuation functions". So, you'd submit the work that has to be done under a lock to a serial queue instead. You'd submit it asynchronously. Any work that has to happen after the work done under the lock should be submitted asynchronously to a concurrent queue at the end of the serialized work. Etc.

The intent is to always allow every thread to make progress and then go back to the pool.

The main thing to worry about is doing work that may require that the thread waits.

Yeah, this.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Can you explain why having lots of serial queues is not a great idea?

What are the pitfalls / drawbacks of using this approach?