Can I call [self retain] within -dealloc? Or, how do I ensure dealloc happens on the main thread?

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 开发者_如何学Python-dealloc gets called on the main thread?

---

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.

---

Why not just avoid passing your view to the block that's executed on a background thread? You could have the controller register for a notification, and have the block issue the notification on the main thread's notification center:

NSNotification *notification = [NSNotificationnotificationWithName:@"data upated" object:nil];
[[NSNotificationCenter defaultCenter] performSelectorOnMainThread:@selector(postNotification:) withObject:notification waitUntilDone:NO];

---

Ive seen this approach used:

- (void)dealloc {
  if (is on main thread) {
    [self _reallyDealloc];
  } else {
    [self performSelectorOnMainThread:@selector(_reallyDealloc)];
  }
}

- (void)_reallyDealloc {
  [ivar release];
  [super dealloc]
}

This still isn't ideal (and breaks in ARC). The best answer is to guarantee that the final release happens on the main thread.

_{pardon the pseudo code. Typing code on an iPhone is sub-optimal}

---

Once dealloc is called, it's too late. That object will go away, no matter what you do. If the problem is that dealloc does things that are not safe to do on a background thread, then dealloc can dispatch these things to the main queue, where they will be performed when the "self" is long gone.

Overriding "retain" is quite perverted. Let's say it's not something you should do when you ask for advice on stack overflow.com. And then there's ARC where you can't do this anyway.