On 4 Dec 2012, at 18:29, Jens Alfke <j...@mooseyard.com> wrote: > On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > >> My app creates lots of MyOperations (subclass of NSOperation) and puts them >> into an NSOperationQueue. >> I would expect that the app thus remains responsive, but sometimes it is not. > > Welcome to the joys of multithreaded programming. :-P You have to be pretty > careful about how you do things, or all sorts of unintuitive and flaky > behaviors can result. > >> + 1343 >> MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, >> unsigned char) (in HIToolbox) + 625 [0x7fff90ea5063] >> + 1343 BroadcastToolboxMessage (in HIToolbox) + >> 294 [0x7fff90e6e12a] >> + 1343 >> HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 >> [0x7fff8e57f174] >> + 1343 CFNotificationCenterPostNotification >> (in CoreFoundation) + 115 [0x7fff95edbbf3] >> + 1343 _CFXNotificationPost (in >> CoreFoundation) + 1109 [0x7fff95ecced5] >> + 1343 -[_NSDNXPCConnection >> sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] >> + 1343 _dispatch_semaphore_wait_slow >> (in libdispatch.dylib) + 241 [0x7fff97ed0486] >> + 1343 semaphore_wait_trap (in >> libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] >> >> >> I have no idea, what this means. >> Maybe someone can enlighten me. > > The main thread is sending a cross-process (XPC) message and waiting for a > reply. Presumably this has something to do with arbitration of the menu bar > state since the menu bar is a shared resource between apps? But it doesn’t > seem related to anything you’re doing.
Is it possible that the XPC that's being waited for here is stalled because whatever's meant to respond to it is a default priority GCD-dispatched block that can't run because GCD has scheduled a lot of your operations, also at the default priority, and won't schedule another (e.g. the one to reply to that message) until the load lightens? I know this sounds unlikely, but it bit me in an iOS project - I was seeing multi-second stalls on the main thread because of this. I 'solved' my problem by lowering the CGD queue priority of my operations. This took care of the large stalls, but to actually get a non-jerky UI, I also had to limit the maxConcurrentOperationCount on my queue to stop GCD from scheduling too many of the operations at once and bogging down the CPU. GCD scheduled too many otherwise because it was fooled into thinking there were resources available whenever a running operation stalled on I/O for a short period. Full details, including samples, are here: https://devforums.apple.com/message/756881. One of the selling points of GCD is that it manages all of this for you, of course, but I've found that's not the case when multiple parts of the system are expecting to be able to use it at once and don't coordinate - especially if there's I/O going on anywhere. Jamie. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
