On 4 Dec 2012, at 18:31, "jonat...@mugginsoft.com" <jonat...@mugginsoft.com>
wrote:
>
>
> On 4 Dec 2012, at 10:29, 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.
>>
>> A sure way to beach-ball my app is: start it with a few hundred operations
>> (which will take about 20 seconds to finish).
>> Make some other app active.
>> Try to make my app active again - it's panel stays grey and after a few
>> seconds the cursor will turn into a beach-ball.
>>
>> These MyOperations interact with their controller in two ways:
>>
>> 1. they do once at start: [ controller dataStringFor: row ];
>>
>> The controller has:
>>
>> - (NSString *) dataStringFor: (NSUInteger)row
>> {
>> @synchronized(self)
>> {
>> if ( self.stringArray == nil ) { create it - takes some time,
>> but happens only once};
>> }
>> return self.stringArray[row];
>> }
>>
> Does the app also access the controller object?
The controller is also the app delegate.
> You are locking the controller so the main app's performance may also be
> affected if the controller is shared with the main thread.
The code inside @synchronized is absolute minimal. I will be used every 50
milli-seconds. Cannot believe this blocks the controller.
>
>
> In the absence of Instruments I would at least experiment with no oping the
> @synchronized methods and try and exclude them as a problem source.
Did comment out both @synchronized lines - same problem - no change at all.
Kind regards,
Gerriet.
_______________________________________________
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
