I have an app that routinely calls [[NSDocumentController sharedDocumentController] recentDocumentURLs] to rebuild a list of recently opened items. This has been working well for a while now, but I recently got a report that it hangs a user's system:
11 -[NSDocumentController(NSPrivate) _recentDocumentURLsForKey:] + 271 (AppKit + 5903428) [0x7fff92ae5444] 1-11
11 -[__NSOperationInternal _waitUntilFinished:] + 131 (Foundation + 1060402) [0x7fff86a1ee32] 1-11
11 __psynch_cvwait + 10 (libsystem_kernel.dylib + 94046) [0x7fff8dec6f5e] 1-11
*11 psynch_cvcontinue + 0 (pthread + 30281) [0xffffff7f80e8d649] 1-11
For the user reporting the bug, this started occurring after an upgrade to El Capitan - he routinely loads files from network shares, so I guess the system is blocking the call trying to locate the files. Looking around, it seems to be an issue that's been around for a while: http://www.cocoabuilder.com/archive/cocoa/317137-thread-deadlock.html and http://ticket.macromates.com/show?ticket_id=F3058D68.
The problem is, while several applications report that the issue is fixed, I haven't been able to track down the actual fix. What would be a suitable way to fix this? Is offloading it to a background thread the only suitable solution, or is there something that I'm missing?
FWIW, I worked around this by calling recentDocumentURLs in a separate thread, at app startup. Once the list is available, I place the URLs into an NSMutableArray, and from that point on update both NSDocumentController and the NSMutableArray.
To replicate the behavior of NSDocumentController using the array (keep only the unique URLs), I remove all URLs matching the new URL, then insert the new one at position 0.