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?
- (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];
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With