Why do NSBlocks have to be copied for storage in containers?

Question

- (void) addABlock 
{
void (^aBlock)(void) = ^() { [someObject doSomething]; };

[self.myMutableArray addObject: aBlock];  // Oops..

[self.myMutableArray addObject:         


        

Answer 1

Under ARC, you no longer need to manually copy blocks in this case, or in most others. According to clang's ARC documentation on blocks

With the exception of retains done as part of initializing a __strong parameter variable or reading a __weak variable, whenever these semantics call for retaining a value of block-pointer type, it has the effect of a Block_copy. The optimizer may remove such copies when it sees that the result is used only as an argument to a call.

In other words, most of the time, retaining a block has the effect of a Block_copy as you were suggesting should be the case. In particular, when the block is added to a collection, it is copied! (More accurately, it is already on the heap.) Here is some sample code that demonstrates that this is the case.

#import 

int main(int argc, char *argv[]) 
{
    @autoreleasepool 
    {
        NSMutableArray *arr = [[NSMutableArray alloc] init];
        int counter = 0;
        int total = 5;
        for (int i = 0; i < total; i++) {
            void (^block)(void) = ^{
                NSLog(@"in this block, counter is %d", counter);
            };
            [arr addObject:block];
            counter += 1;
        }

        for (int i = 0; i < total; i++) {
            void (^block)(void) = arr[i];
            block();
        }
    }
}

If run on the latest Xcode (4.6.3 (4H1503)) with the default compiler (Apple LLVM compiler 4.2), the output for this will be

in this block, counter is 0
in this block, counter is 1
in this block, counter is 2
in this block, counter is 3
in this block, counter is 4

If these blocks were not copied to the heap, you would (probably--this is undefined behavior) see

in this block, counter is 4
in this block, counter is 4
in this block, counter is 4
in this block, counter is 4
in this block, counter is 4

because the pointers added to the array were all pointing to the stack-allocated (non-copied) block which--at the time that the blocks were executed--had captured a counter value of 4.

In particular, this is the same behavior that you will get if you disable ARC. Even if you call retain on the blocks before adding them to the array

[arr addObject:[block retain]];

you will still get the same ("broken") output, illustrating that this is an ARC behavior, not a retain behavior in general.

Note:

The two places where ARC's retain does not have the effect of Block_copy are

(1) retains done as part of initializing a __strong parameter variable

Immediately upon entering a function (or method), if an object is passed to that function (or method), that object will be retained (there is a strong reference to the object in the stack frame) and released when the function (or method) exits (the strong reference to the object is released).

This is just as true of blocks as it is true of any other object. This phrase in the clang documentation means that even though the block is retained in this case, the block will not be copied by this retain.

(2) retains done as part of reading a __weak variable

Similarly, when a __weak variable is read into a __strong variable, a strong reference to the object is created, and the object is retained.

This is the case for blocks as well. Blocks which are sent retain in this way (as a result of reading a __weak reference into a __strong reference), though, are not copied.

The cases where either of these two exceptions will cause you problems are rare. In general, you don't need to worry about copying your blocks.