Re: Spinning the busy indicator
Re: Spinning the busy indicator
- Subject: Re: Spinning the busy indicator
- From: Roland King <email@hidden>
- Date: Fri, 01 May 2015 12:20:38 +0800
Doing a little bit of googling on some of the stuff in your stack trace, InstallEventHander and GlobalRegistryEventRegistered all seem to be part of HIToolBox.
I just picked a random app of my own and stuck a few breakpoints in it to find every menu invocation in my app goes down pretty much the same path, including the synchronous xpc call following HIToolbox adding and removing event handlers, more than one actually. Every one. Just sticking logging on the synchronous xpc calls generates a lot of guff when you open a menu.
All this seems to be calling out to some piece of LaunchServices with ‘addasn’ and ‘removeasn’ messages (looking up the stack you can see the strings put into the xpc dictionary). So the act of opening a menu appears to be registering for notifications from launchservices, I’m guessing so that it knows if the app ceases to be frontmost or similar.
So I don’t think this has anything to do with your code at all, apart from the fact your code makes the machine really busy. It seems the menu system does a synchronous call out to an XPC service which doesn’t return in a timely manner when the cpu is busy. This is all in the OS code (I’m on Yosemite by the way).
Noting the documented warning for using xpc_connection_send_message_with_reply_sync()
"If the response will be constructed with data that exists in-memory in the server, it is usually safe to make the API synchronous. But if constructing the response requires I/O, and it is likely to be called from the main thread (or a thread which synchronizes with the main thread), we highly encourage that you take the asynchronous route to avoid the risk of blocking the UI.”
> On 1 May 2015, at 10:59, Roland King <email@hidden> wrote:
>
>
>
>>
>> Stumped.
>>
>> —Graham
>>
>
> I don’t have a lot more ideas than you, having been reading this thread (no pun intended) for 2 days.
>
> Is this only happening when you click to bring up a menu when your app is running or at other times too? I can’t currently think of a good reason why opening a menu ends up resulting in an XPC call, worse, an XPC call which is synchronous and waits for a reply, on the main thread. Do the classes/methods in the trace, InstallEventHandler(), TEventTypeIndex, GlobalRegistryEventRegistered and LSNotificationReceiver mean anything to you, or anyone else?
>
> Might be time to grit teeth and break out Instruments. That can quite usefully show you breakdowns by queue, by thread or by processor. Sometimes just looking at the pattern gives you a clue what’s happening. It will surely tell you if you have the CPUs all spun up to 100%.
>
> The xpc call which is hanging. Are xpc services always separate processes, I thought so but someone can correct me if wrong. If so, it sounds like the xpc service being used is starved of resources because the CPUs are busy mandelbrotting, so it doesn’t reply very quickly and blocks your main thread. If you open and close menus on a barebones system running just your app, can you find another process which keeps spinning up?
>
> It looks to me that opening a menu calls some xpc service which is expected to return quickly but doesn’t because the machine is swamped (Instruments should be able to tell you if it is). Whether that xpc call is something the OS does all the time or if there’s something in your app which is causing it, can’t say. Synchronous calls to xpc services from the main thread would seem to be something Apple is always telling devs not to do, so it’s probably them.
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden