Setting the block to nil within the block itself actually did the trick.
Thank you very much for the quick reply and the correct solution! :)
Andreas
On Sep 30, 2010, at 5:21 PM, Dave DeLong wrote:
> By referencing instance variables within the block, you're causing the block
> to retain self, and since self retains (copy'd) the block, you've got a
> retain cycle.
>
> The easiest way to fix this is to break the retain cycle yourself. Doing
> "[self setCompletionBlock:nil];" at the end of the block should be adequate.
>
> Dave
>
> On Sep 30, 2010, at 9:17 AM, Andreas Grosam wrote:
>
>> I've subclassed a NSOperation and declared a completion block in the
>> initializer as follows:
>>
>> - (id) initWithParameter:(id)parameter
>> {
>> self = [super init];
>> if (self != nil) {
>> [self setCompletionBlock:^{
>> NSLog(@"operation completed");
>> [someIvar release], someIvar = nil;
>> }];
>>
>> // ... initialize ivars
>> }
>> return self;
>> }
>>
>>
>> The problem is now, once a completion block has been defined and set as
>> shown above, the NSOperation instance will never be dealloced. I noticed,
>> when -setCompletionBlock: returns, the retain count of the NSOperation
>> instance has been incremented by one.
>>
>> When there is no completion block set, the NSOperation object will be
>> deallocated as expected some time later when the operation finished.
>>
>> The -initWithParameter: method is invoked on the main thread.
>>
>> The code of the completion block is trivial: It logs to the console and
>> simply releases certain ivars. So, there should no autoreleased object
>> (namely the operation object itself) left in some unknown execution context
>> possibly without a pool and hence leaking.
>>
>>
>> As a side note: according the docs, the exact execution context for the
>> completion block is undefined. So, I think this means, we should better use
>> synchronization primitives when accessing ivars since the dealloc method
>> might still executing, right?
>>
>>
>> This is running on iOS.
>>
>>
>> Any hints?
>>
>>
>>
>> Thanks in advance
>> Andreas
>> _______________________________________________
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
