I think you’re mixing up two problems. In this context overcommit is Dispatch’s attempt to keep the CPU busy by starting new threads to run work on queues when the existing queue worker threads have blocked on I/O. Overcommit is bad — it’s much better to do that I/O work asynchronously and thus avoid the overcommit — but it generally won’t trigger an unrecognized selector exception. Such exceptions are usually caused by memory management problems.
Do you have an Apple crash report for this unrecognized selector exception? If so, please post it.
Regardless of the above, if you’re having overcommit problems that’s definitely something to look into. Excessive reliance of overcommit can result in a thread explosion, the symptoms of which are deadlocks or excessive latency. For more info about this problem, see WWDC 2015 Session 718 Building Responsive and Efficient Apps with GCD. And for specific guidance on how you should structure your Dispatch code to avoid problems like this, watch WWDC 2018 Session 706 Modernizing Grand Central Dispatch Usage
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
I am awaiting the specific crash report for the example I provided. I appreciate the explaination and resources to track the overcommit side of this. The crash is occuring within our library implemented in a customer's app environment, where they just implemented a thread management system, hence the reason why there is some suspicion that the crash is from a new latency in the way threads are serviced.
When I have a crash report I will post it.