ARC __block behavior equivalent in MRC?

Question

As you know, in ARC, __block variables of object pointer type used in a block are retained by the block. So take the following simplified example:

__block id foo = getObject();
void (^aBlock)() = ^ {
    NSLog(@"%@", foo);
    foo = getObject();
}
runBlockAsynchronouslyMultipleTimes(aBlock);

The object pointed to by foo is retained by the block, so that when the block is run (asynchronously), the object is still valid and can be printed. When we do the assignment within the block, ARC manages it like any other strong reference (the old value is released and the new value retained). (The assignment forces us to use __block in the first place.) And when the block is not needed anymore, ARC somehow releases its retained object pointed to by foo at that point (it is not leaked).

Okay, now suppose I want to do the same thing under MRC (why is not important; this is an question about the language). As you know, __block variables of object pointer type used in a block are NOT retained by the block in MRC. Which is fine; we'll manage it ourselves (this is MRC, after all). So the attempt looks like this:

__block id foo = [getObject() retain];
void (^aBlock)() = ^ {
    NSLog(@"%@", foo);
    [foo release];
    foo = [getObject() retain];
}
runBlockAsynchronouslyMultipleTimes(aBlock);
// where to release foo?

Most of it is straight-forward -- the object is retained by us initially manually; inside the block, when we re-assign the pointer, we release and retain the new value as appropriate.

But then comes the problem: How do we release the object when the block is not needed anymore? Since we manually manage the memory, we should ideally manually release the object when the block is deallocated. But there doesn't seem to be an easy way to do so.

I could think of maybe one way: using associative references to tie the object to the block. But then to re-assign the associative reference inside the block, the block would need a reference to itself, so the block variable would also need to be __block and the block needs to be copied prior to setting the variable. Which is all very ugly. Or, we put the object inside a mutable container object that is then retained by the block; but that is ugly too.

When your runBlockAsynchronouslyMultipleTimes() is done dispatching your aBlock multiple times, you would simply do one additional, final dispatch of a [foo release] (using a dispatch barrier if your queue was concurrent, which it obviously is not in this case). Far simpler and more logical than associated references or anything like that. — Rob
@Rob: that depends on knowing what runBlockAsynchronouslyMultipleTimes() does internally. Sure, it may work in this particular case; but not in general -- what if in addition to being dispatched multiple times the block is also possibly stored somewhere else and possibly called later, in an unpredictable way? — newacct
Agreed. But generally when using __block for the variable declaration, you're already engaged somewhat in what the block is doing internally, implicitly stating that the calling method is the owner, that the block will update it, but generally that the caller still assumes responsibility for clean up (hence if your blocks are running asynchronously, the caller will dispatch the clean up asynchronously, too). Personally, I find the whole notion of repeatedly updating a method's local variable asynchronously (beyond the life of the method) a little curious. — Rob
I think these sorts of theoretical questions fall into stark relief when you start considering practical situations where you are contemplating using this pattern. Do you have such a scenario in mind? Then you can ask yourself how you would remedy the code sample, or ask yourself whether you might refactor, employing a simpler pattern. — Rob

ughoavgfhw ughoavgfhw · Accepted Answer · 2012-10-03T20:11:23

The mutable container is about as clean as you can get. You could create a simple wrapper with a single object property to clean it up a little, and then you would get memory management from the property accessors.

An approach which would look cleaner, but is actually kind of messy underneath, would be to have an immutable wrapper which took a pointer, and just released that pointer when it was deallocated.

@interface ObjectReleaser : NSObject {
    id *objectPointer;
}
- (id)setObjectPointer:(id *)pointer;
- (void)captureMe;
@end

@implementation ObjectReleaser
- (void)setObjectPointer:(id *)pointer {
    if(!objectPointer && pointer) {
        objectPointer = pointer;
        [*objectPointer retain];
    }
}
- (void)dealloc {
    if(objectPointer) [*objectPointer release];
    [super dealloc];
}
- (void)captureMe {} // Blocks can call this to capture the object
@end

The block would catch and retain this object, since it is not __block. You would modify your __block object as usual, with all of the proper retains and releases. Then, when the block is deallocated, it will release the releaser, which will then be deallocated and release whatever your pointer currently points to.

__block id foo = getObject();
ObjectReleaser *releaser = [[ObjectReleaser alloc] init];
void (^aBlock)() = ^ {
    [releaser captureMe];
    NSLog(@"%@", foo);
    [foo release];
    foo = [getObject() retain];
}
aBlock = [aBlock copy];
[releaser setObjectPointer:&foo];

Note that you don't need to retain foo just for the block, because the releaser does that for you. You do have to set the releaser's pointer after copying the block, since the copy will change foo's pointer. This is also why it is safe to save the pointer of a stack variable after your function returns: the variable is not actually on the stack.

ARC __block behavior equivalent in MRC?

1 Answers