> On 1 May 2015, at 10:18 am, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Apr 30, 2015, at 16:39 , Graham Cox <graham....@bigpond.com> wrote: >> >> As I mentioned it’s the spinning busy indicator, which is always >> indeterminate. > > The circular style isn’t always indeterminate, though (I forgot) it looks > different when it’s not indeterminate.
Well, the docs say: > This method only has an effect if style returns NSProgressIndicatorBarStyle. > If style returns NSProgressIndicatorSpinningStyle, the indicator is always > indeterminate, regardless of what you pass to this method. However, I’m now fairly convinced that this is a red herring, and is a side effect of the more serious bug. > > My app also hits a breakpoint at _dispatch_semaphore_wait_slow when I click > on a menu bar menu, also in the middle of talking to another process via XPC, > so I don’t think that’s a cause of your problem. > > Instead, I suspect you have a memory management error that’s corrupting > something. Or a thread safety error that’s causing this as a side effect. I’m starting to think that as well. I’m using ARC - I keep trying to get on board with ARC, and every time I do I seem to run into this sort of difficult to track down issue. At this stage I’ll try and persist with it, because I’m not getting any problems when I use any of the memory managment debugging aids such as zombies and guard malloc, etc. So perhaps as you suggest it’s more of a thread safety issue. I can well believe it could be, as I’m just exploring using NSOperationQueue for this kind of processing, and maybe I’ve just done it wrong. The app here is only an experiment - if I can get it to work properly it’ll be useful experience that I can apply to other situations. So I’m drawing a portion of the Mandelbrot set in a view. I tile the view into a number of tiles and each one is given the appropriate coordinates and goes away and does the calculation work in a block added to an NSOperationQueue. Plotting the Mandelbrot set is a good experiment because it is eminently parallisable without any co-dependencies between tiles - it just needs to keep track of which part of the overall view it belongs to. When the calculation for a tile is finished, it calls its delegate to tell it it has finished. The delegate is the original view. I use -performSelectorOnMainThread: to notify the delegate. In response, it takes a bitmap that the tile created and filled in, and draws it in the view (well, it’s a little more complex. When the delegate of the tile gets the ‘finished’ notification, it adds the tile to a dictionary of tiles that can be drawn, keyed by a string version of the tile’s coordinates, then it calls -setNeedsDisplayInRect: for that tile. When -drawRect is called, it iterates through the dictionary drawing tiles that intersect the dirty region of the view.) That all works fine - as each tile completes, I see the view plot that tile, so gradually the view fills with the complete image. Pursuing the corruption/thread safety angle, if I set it to just use 1 tile for the view, all is well. The spinner spins and the menubar doesn’t block. If I go to 2x2 tiles, it’s still OK. Any more than that and the menubar click blocks the main thread and the spinner doesn’t animate. Thus the problem is sensitive to the number of tasks I add to the NSOperationQueue. The code that schedules the work is: if( !self.busy ) { mBusy = YES; [[[self class] mandelGeneratorQueue] addOperationWithBlock:^ { [self createBitmapIfNeeded]; if([self.delegate respondsToSelector:@selector(mandelGeneratorWillStartCalculation:)]) [self.delegate performSelectorOnMainThread:@selector(mandelGeneratorWillStartCalculation:) withObject:self waitUntilDone:NO]; NSUInteger x, y, xm, ym; size_t index; NSRect dr = self.destinationRect; x = xm = NSWidth( dr ); y = ym = NSHeight( dr ); while( y-- ) { x = xm; while( x-- ) { CGFloat ev = [self calculateEscapeValueAtX:x y:y]; [self plotEscapeValue:ev atX:x y:y]; } } mBusy = NO; if([self.delegate respondsToSelector:@selector(mandelGeneratorDidFinishCalculation:)]) [self.delegate performSelectorOnMainThread:@selector(mandelGeneratorDidFinishCalculation:) withObject:self waitUntilDone:NO]; }]; } If I replace the work done in the inner loop with usleep( 10 ), I still see the same problem, so whatever the cause of the issue it isn’t a fault with the actual Mandelbrot calculation, but with the whole tile plotting on a thread architecture. Stumped. —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