5

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?

easeout
  • 8,665
  • 5
  • 43
  • 51
  • 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. –  Apr 24 '11 at 07:48
  • 1
    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. –  Apr 24 '11 at 07:52
  • @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? – easeout Apr 24 '11 at 07:58
  • @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? – easeout Apr 24 '11 at 08:00
  • I don’t see how `-dealloc` would be sent twice. –  Apr 24 '11 at 08:00
  • @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. – easeout Apr 24 '11 at 08:03
  • [My Solution (uses an NSTimer for the last release)](http://stackoverflow.com/questions/6353471/block-release-deallocating-ui-objects-on-a-background-thread/6482941#6482941 "My solution") – Jeff Jun 26 '11 at 08:40

4 Answers4

6

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.

unexpectedvalue
  • 6,079
  • 3
  • 38
  • 62
  • 1
    RIGHT ON. Thanks, that is much less insane. – easeout Apr 24 '11 at 08:09
  • 11
    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. – bbum Apr 24 '11 at 08:14
  • 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. – unexpectedvalue Apr 24 '11 at 10:17
  • 1
    @bbum 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. – easeout Apr 25 '11 at 21:18
  • 1
    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. – easeout Apr 25 '11 at 21:20
  • 3
    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. – Ken Thomases Apr 13 '13 at 09:19
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];
Christopher Pickslay
  • 17,523
  • 6
  • 79
  • 92
  • Upvoted, because the original problem occurred because of allowing View and Model objects to interact directly, rather than through Controllers. – ilya n. Nov 26 '13 at 23:57
1

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.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
1

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

Dave DeLong
  • 242,470
  • 58
  • 448
  • 498