The magic of NSOperation internals - how does it notice the isFinished key, so that completeBlock always starts?

Question

Demonstration

- (void)test_NSOperationCallsCompletionBlockWhenFinished { __block BOOL flag = NO; NSOperation *operation = [NSOperation new]; operation.completionBlock = ^{ NSLog(@"Hunting NSOperation internals: %@", [NSThread callStackSymbols]); flag = YES; }; [operation start]; while (flag == NO); STAssertTrue(flag, nil); } 

Gives me the following input:

 2013-07-28 19:59:44.690 SACompositeOperationsApp[99551:3103] Hunting NSOperation internals: ( 0 SACompositeOperationsApp 0x000000010005bbd9 __68-[SAOperationTests test_NSOperationCallsCompletionBlockWhenFinished]_block_invoke + 41 1 Foundation 0x00007fff8a27bb25 __+[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:]_block_invoke_3 + 55 2 libdispatch.dylib 0x00007fff8abd9a82 _dispatch_call_block_and_release + 18 3 libdispatch.dylib 0x00007fff8abdb083 _dispatch_async_f_redirect_invoke + 112 4 libdispatch.dylib 0x00007fff8abda961 _dispatch_worker_thread2 + 255 5 libsystem_c.dylib 0x00007fff91ce13da _pthread_wqthread + 316 6 libsystem_c.dylib 0x00007fff91ce2b85 start_wqthread + 13 ) 

---

Background

I did some experiments with my subclasses of NSOperation - I tried to add my own observers to the isFinished property, and they worked well as expected.

These experiments made me wonder how NSOperation calls it completionBlocks based on its observation of changes to the isFinished properties -

What I do not understand and why this question is that my observers from the isFinished property never interfere with NSOperation (if I add them, delete them ...), so the logic is observe isFinished -> invoke completionBlock when it becomes YES encapsulated pretty well, giving me the freedom to do extra KVO observations without any problems:

1) I did a couple of tests showing that NSOperation does some kind of magical subscription to observe property changes right in my -[NSOperation init] - I don’t know what is going on there, but I made sure that it has something to do with "isFinished-> completeBlock" goes there . I wonder what was done there, except for the general - [NSObject init] logic?

2) The NSLog output shows that it is not an NSOperation class, but calls some mysterious NSOperationInternal with observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context: which finally causes the completion.

3). As far as my understanding can go, the GNUStep implementation of NSOperation differs in implementation details (at least in the described isFinished-completionBlock , see, for example, _ completion method ), so I can not use it as an assistant to understand Apple's approach to that as NSOperation is written.

---

NB

I have no problems, I just want to understand more deeply how NSOperation works internally in terms of isFinished observing -> completionBlock invocation .

I don’t want to see: "The internal elements of Apple are hidden, it is impossible to find out by non-Apple engineers." I want to see an answer that contains a deep understanding of this topic.

Answer 1

This is what I know about the NSOperation life cycle, it is not much, but enough to answer my original question:

• NSOperation registers KVO monitoring of the isFinished property in its -init method. This means that the observation is logged even if I never ran the -start ( main ) method (I did some experimenting with a custom subclass of NSOperation to determine this). The corresponding deregistration is done in the NSOperation -dealloc method (I cannot prove it, but this is really the only place where this can happen).

• To make KVO possible and "private" NSOperation has some inner container class NSOperationInternal that encapsulates its own KVO NSOperation procedures, giving me the freedom to make my custom KVO when I want to implement it for instances of my custom subclasses of the NSOperation class. In my NSOperation subclasses, I can use my own implementation of the observeValueForKeyPath:ofObject:change:context: method, without worrying about possible conflicts with my own KVO NSOperation, because this will not interfere with this method implemented in NSOperationInternal.

PS As for the word "magic" - I know that this is all KVO behind the curtains, so no surprises here are not about KVO. My surprise is how KVO is applied to NSOperation in specific details: there is nothing magical here, but it was not quite obvious when I first started introducing my own KVO and began to suspect possible interference.