Open Radar

 
When NSUbiquitousKeyValueStore performs its automatic synchronisation (via a NSTimer calling _syncConcurrently on the main thread) it calls the xpc_connection_send_message_with_reply_sync() function on the main thread too. As per Apple's own API documentation (http://developer.apple.com/library/mac/documentation/System/Reference/XPC_connection_header_reference/XPC_connection_header_reference.pdf) this should NOT ever be done, as this function could block.

In most circumstances and small tests, this is NOT blocking for any noticeable time. HOWEVER we have a game where this function call *is* blocking the main thread for a few seconds - we have specifically traced the blockage to the automatic _syncConcurrently method of NSUbiquitousKeyValueStore and when pausing XCode while the app is pinWheeling,  it is always waiting for a semaphore as per the attached screen shot.

Steps to Reproduce:

Any application, that writes to NSUbiquitousKeyValueStore can clearly show that xpc_connection_send_message_with_reply_sync() is being called on the main thread - and thus there is a possibility of this blocking the main thread, as per the documentation. 

1. Simply add a symbolic breakpoint in XCode for "xpc_connection_send_message_with_reply_sync", 

2. write to the NSUbiquitousKeyValueStore

3. After 10-20seconds when the automatic synchronisation occurs, the breakpoint triggers and one can see that the function is being called on the main thread. 

Expected Results:

xpc_connection_send_message_with_reply_sync should not be called on the main thread as per the documentation as it can block. 

Actual Results:

xpc_connection_send_message_with_reply_sync is being called on the main thread - and is at risk of blocking.