> On 1 May 2015, at 1:12 pm, Quincey Morris
> <quinceymor...@rivergatesoftware.com> 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 <r...@rols.org> 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 (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
