> On 30 Apr 2015, at 11:22 am, Graham Cox <graham....@bigpond.com> wrote: > > My guess is that the busy indicator is animated by a low-priority thread of > its own, and the work being done by my queue has a higher priority so the > animation thread never gets any time. Does that sound like a reasonable > explanation? If so, is there any way to make sure that the spinner actually > spins?
OK, I’m a lot less sure about this now. I noticed that my main thread is blocking for some reason after I kick off a number of operations on my operation queue. This remains blocked for some time - it appears as if it’s waiting on some of the operations to complete, which is defeating the entire purpose of using the queue. I’ve checked and none of the queued tasks end up on the main thread, which is in line with my expectations having read the docs. My main thread looks like this: Thread 1Queue : com.apple.main-thread (serial) #0 0x00007fff8dd7851a in semaphore_wait_trap () #1 0x00000001000477e0 in _dispatch_semaphore_wait_slow () #2 0x00007fff90eedddd in xpc_connection_send_message_with_reply_sync () #3 0x00007fff91d76150 in LSNotificationReceiver::modify(unsigned long, LSNotificationCode const*, unsigned long, LSNotificationCode const*, void const*, void const*) () #4 0x00007fff91d76ac4 in _LSModifyNotification () #5 0x00007fff99fad0b4 in HandlerStatusChanged () #6 0x00007fff99faa1a0 in GlobalRegistryEventRegistered(unsigned int, unsigned int) () #7 0x00007fff99fa9ea8 in TEventTypeIndex::AddTypes(unsigned long, EventTypeSpec const*) () #8 0x00007fff99fa9adf in AddHandlersToIndex(EventTargetRec*, HandlerRec*, unsigned long, EventTypeSpec const*) () #9 0x00007fff9a129e1e in PushEventHandler(EventTargetRec*, int (*)(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*), unsigned char, unsigned long, EventTypeSpec const*, void*, OpaqueEventHandlerRef**) () #10 0x00007fff99faca07 in InstallEventHandler () #11 0x00007fff9a015af1 in SetupMenuTracking(MenuSelectData&, unsigned char, Point, double, MenuData*, unsigned int, unsigned short, Rect const*, Rect const*, __CFDictionary const*, unsigned int, Rect const*, __CFString const*) () #12 0x00007fff9a0392cf in MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) () #13 0x00007fff9a0390fe in _HandleMenuSelection2 () #14 0x00007fff8fab2de0 in _NSHandleCarbonMenuEvent () #15 0x00007fff8f9e9d0d in _DPSNextEvent () #16 0x00007fff8f9e8f68 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #17 0x00007fff8f9debf3 in -[NSApplication run] () #18 0x00007fff8f95b354 in NSApplicationMain () (This was caught when I clicked in the menu bar after starting my tasks). The remainder of my threads are in various stages of execution, and appear to be what I’d expect. I’m pretty sure this wasn’t happening earlier on in the development of this, so something I’ve done has caused this to change. I’m not explicitly using any locks anywhere, nor any @synchronized blocks. I add my tasks to be executed to my queue using -addOperationWithBlock: The object that hosts that code has a couple of atomic properties because they can be set either from the main thread or read by the task block. So there’s an implied lock there, but I’m not accessing those properties at the time the main thread is blocked here. Probably without posting my entire code it’s likely going to be hard for anyone to pinpoint the issue, but what’s weird is that my main thread really should just be sitting there doing nothing, not waiting on a lock like this. Is there any way to tell in the debugger what other thread it’s waiting on? That might help me to figure out where the hold up is arising at least. —Graham _______________________________________________ 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
