Re: Spinning the busy indicator
Re: Spinning the busy indicator
- Subject: Re: Spinning the busy indicator
- From: Graham Cox <email@hidden>
- Date: Fri, 01 May 2015 14:46:53 +1000
> On 1 May 2015, at 1:12 pm, Quincey Morris <email@hidden> wrote:
>
> Yes, they do say that. But as it happens I went to IB (6.3.1). The “indeterminate” checkbox is right there, and if you uncheck it you get a clock-style progress indicator. I guess the docs are out of date, though only by about 4 or 5 major OS X versions. ;)
You’re right - there is another style of circular spinner you get with indeterminate = NO. Never noticed that before. And you’re right - the docs are out of date.
> I don’t have any answers here, just some random thoughts:
>
> — Looking at your code, my intuition says that this smells like a reference cycle problem, one that leads to queue blockage.
>
> — Don’t use ‘performSelector…’ with ARC, since it typically can’t preserve memory management correctness across that boundary. It’s uglier but preferable to get back to the main thread via ‘dispatch_async (dispatch_get_main_queue (), ^{ … });’. There’s an autocompletion snippet for most of this.
>
> — I’m not a big fan of NSOperationQueue. A simple GCD dispatch_async to the default non-main queue seems more obvious to me. The only reason for using NSOperationQueue is if you want a parallel operation count other than 1 (i.e. serial) or “let the system decide” (i.e. the GCD default), provided that the individual operations don’t block internally, which tends to mess GCD up. Or if you want to be able to cancel operations, since there’s no API for that in GCD itself. Or if you want selector-based operations rather than the block-based ones you’re using.
>
> — For anything to do with blocks running on background GCD threads, you need to pay attention to the top level autorelease pool, and the place where exceptions are caught. IIRC, in vanilla GCD, you have to provide these yourself, but I don’t remember the NSOperation semantics.
Well, here’s a huge clue.
I use NSOperationQueue with the default -maxConcurrentOperationCount which is NSOperationQueueDefaultMaxConcurrentOperationCount, i.e. let the system figure it out. That appears to create 4 threads for my particular machine, which has a Core i3 (2 cores) CPU. My peak CPU usage is reported as 418%. I’m not sure how it achieves that from a dual core CPU, but one would assume that Apple know what they’re doing [/irony].
So, I tried setting that NSOperationQueue property directly to something less, and lo-and-behold, the problem goes away with a limit of 3 or less. A limit of 4 produces the same problem.
This appears to suggest that if you let NSOperationQueue take all of the CPU resources, the main thread is left high and dry if it needs to create another thread, e.g. for an XPC call. Maybe this is intentional, but it’s a bloody nuisance - surely a better outcome for the “let the system figure it out” would be to say “whatever the max is -1”, so it leaves some capacity in hand for the main thread. The way it works now might give slightly better performance overall, but it causes an app to hang unresponsively for some indeterminate period in some cases. Of course I can set the limit to 3 myself, but if I found myself on a 16 core machine, that's very suboptimal.
> On 1 May 2015, at 2:20 pm, Roland King <email@hidden> wrote:
>
> 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).
>
I’m tempted to report this as a bug, but I’d like to hear what others think about this first.
If anyone’s interested in having a look at what’s happening, I’ve put the project sources up here: http://apptree.net/code/Gingerbread.zip As it’s only a toy/experimental project, there’s nothing in it that matters but it’s a bit rough and ready. Line 124 in GCMandelGenerator.m is where I manipulate the queue max count. Commenting that out gives the default behaviour, which shows the problem.
—Graham
_______________________________________________
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