Open Radar

 
Summary:
We would like to request that the NSFilePresenter API is extended with a way to determine, if the NSFilePresenter call was triggered by a coordinated operation from inside the same application or if the call came out of process. 

This would be extremely useful for us (and likely others) to ensure proper behavior and locking when receiving callbacks. This is also unfortunately something that we cannot add on our own in a thread safe manner. A potential solution, that we discussed in the WWDC labs was to provide the fill presenter and/or purpose identifier of the coordinator that triggered the operation (or similar) when invoking file presenter callbacks. 

Steps to Reproduce:
N/A

Expected Results:
NSFilePresenter API would provider a way to determine if a call came from inside the same process (and ideally what object triggered it). 

Actual Results:
NSFilePresenter provides no such API. 

Version:
iOS 11b1

Notes:
Our framework PSPDFKit uses coordinated file operations for file access and implements the file presenter API on our document class to receive various notifications about the file state. To ensure our data and global state (something we sadly can’t avoid just yet) stays consistent, we require strict locking when reading and writing data. This can lead to issues, when we have two or more documents working with the same file on disk. During a read, our main lock needs to be held by the reader, this then ten triggers savePresentedItemChangesWithCompletionHandler: on the second document which needs to do a save by taking the same global lock. This then deadlocks the process. 

The requested API would allow us to determine if the required lock is already held by the blocked called and therefore simply continue saving without locking again, thereby avoiding any possibility of a deadlock.