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

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?

Apparitor

Consider that a superclass retains some objects referenced by its instance variables. If you don’t send [super dealloc], those objects won’t be released. Besides that, a superclass might have other cleanup code in its -dealloc method. – Psychologism

As for sending [self retain] inside -dealloc, that’s bogus. If -dealloc is being executed that means the runtime has already decided that the object must be deallocated. – Psychologism

@Bavarious It does call [super dealloc] -- On the second call to dealloc when the main queue finishes executing the block containing the release. It just doesn't call it during the original call to dealloc. Is that OK? – Apparitor

@Bavarious You say the runtime decided, but is there anything else to it besides observing that the retain count is zero and therefore calling dealloc? I have so far thought that NSObject's implementation of dealloc is what frees the memory, and if that doesn't happen, isn't the object simply still on the heap? – Apparitor

I don’t see how -dealloc would be sent twice. – Psychologism

@Bavarious Like this: dealloc is sent once by the background thread, and you take the else branch. Then self is retained, and a block goes on the main queue. self is retained again by the block's use of it. Later the main queue executes the block. It releases self -- once explicitly, and again when the block is destroyed. The reference count is zero again, and dealloc is called again. This time it takes the first branch because this is the main thread. – Apparitor

My Solution (uses an NSTimer for the last release) – Eyepiece

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.

Kwon

RIGHT ON. Thanks, that is much less insane. – Apparitor

Nope -- it is still pretty darned insane. You are incurring ordering & threading dependencies in your implementation that will prove to be a nightmare going forward. If a class has such onerous tear-down requirements, then tear-down should be exceedingly explicit; there should be a terminate or invalidate or doneWithYou method that is quite explicitly invoked and quite explicitly marks the object as invalid. release or dealloc are the wrong place to do that. – Skein

Actually this proved to save nightmares for me. No dealloc on background threads madness. Besides the tiny (and needed) overhead, no downsides I can see. – Kwon

@Skein But we already have a thread dependency, and the only onerous tear-down requirement is imposed by UIKit itself. It's true that I was the one with the crazy rube goldberg solution to begin with, but I fail to see why only releasing on the main queue is so dangerous. Maybe in the general case, if I were to have hundreds of these objects, but I've got one or two at a time. – Apparitor

One thing I could do is destroy the subviews at the same time as removing the view from its superview, which already happens on the main thread. Then the view's dealloc would not touch the UITextView and it could happen on the background thread, in theory. – Apparitor

This is actually not safe. The -performSelectorOnMainThread:… mechanism itself entails retaining and releasing of the receiver. So, this approach can cause infinite recursion or that sort of thing. Just because you tried it and, in some finite set of circumstances, it worked fine doesn't mean it won't happen in some other circumstances or future releases of the OS. – Animadvert

Answer 2

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];

Roscoe

Upvoted, because the original problem occurred because of allowing View and Model objects to interact directly, rather than through Controllers. – Gooch

Answer 3

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}

Roush

Answer 4

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.

Hispanicism