Question

Here is my situation. It’s complicated so bear with me.

I have a view class, let’s call it MyView. It creates a loading indicator subview, and then starts a background operation that will load data. It also creates a block that the background queue operation will enqueue on the main queue when it’s done. The block prepares the view by adding another subview, a UITextView, with the loaded data. Of course, to do that, the block has to have a reference to the view.

So the background operation retains the block, and the block retains the view. With me so far?

Sometimes the instance of MyView is removed from its superview before the background queue operation is finished. And sometimes the main queue operation, which calls the block, gets completely cleaned up before the background queue operation gets completely cleaned up. In this case, the instance of MyView can get its -dealloc call on the background thread, because the last reference to the view belonged to the block, and the last reference to the block belonged to the background operation.

UIKit doesn’t like to be called from any thread but the main thread. In the case of UITextView, apparently that even includes -dealloc calls. I get EXC_BAD_ACCESS from something called the “web thread lock” during the -dealloc of the text view.

I think it’s reasonable for the background thread to have the last reference sometimes, and I would like to handle this from within my -dealloc implementation, like so:

- (void)dealloc {
    if ([NSOperationQueue currentQueue] == [NSOperationQueue mainQueue]) {
        // The usual -- dealloc subviews safely on the main thread
        self.myIvar = nil;
        [super dealloc];
    }
    else {
        // Not on the main thread, so keep the object alive
        // in spite of the dealloc call.
        [self retain];                   // explicit retain
        [[NSOperationQueue mainQueue]
         addOperationWithBlock:^{        // implicit retain at block creation
            [self release];              // explicit release
        }];                              // implicit release, dealloc called again, but on the main thread
    }
}

So when you call -release on an object, the implementation in NSObject calls -dealloc if the retain count reaches zero. Is that all that happens? In other words, is it OK to get a call to -dealloc and not call super? Am I making some kind of abominable zombie object or is this fine?

If this is not OK, what is a good way to make sure -dealloc gets called on the main thread?

Answer 1

Why not just override release?

- (void)release
{
    if (![NSThread isMainThread]) {
        [self performSelectorOnMainThread:@selector(release) withObject:nil waitUntilDone:NO];
    } else {
        [super release];
    }
}

Edit: This was pre-ARC. Don’t do it with ARC.