Method with blocks inside NSOperation - how does it work?

Question

I'm working on an iOS project that has to work from iOS4. I have an NSOperationQueue and I add an operation. The main method of the operation looks something like this:

-(void)main 
{
    [self.client getStuffSuccess:^(Stuff *s) {
        //Do something on success
    } failure:^(NSError *error) {
        //Do something on failure
    }
}

The code inside the block will only be called when getStuff calls success or failure. I thought that in the meanwhile, my operation would be removed from the NSOperationQueue and the block wouldn't be called. However, I tested it and the block was in fact called. It's called no matter if the client calls the success block on the dispatch_get_main_queue or on the thread that called it - in this case the operation above.

Before the block is called, the method isFinished is actually returning true (I overrode the isFinished method and checked the value), so can someone explain me how is it possible that the block is being called?

I'm asking all this because although this works fine for one call, when I add it in a cycle of a few hundred iterations, I get an EXC_BAD_ACCESS and understanding the above might help me on the debugging.

Is getStuffSuccess:failure synchronous or asynchronous? – jsd Mar 30 '12 at 23:20 — jsd, Mar 30 '12 at 23:20

score 1 · Answer 1 · answered Mar 31 '12 at 03:25

The code inside the block will only be called when getStuff calls success or failure. I thought that in the meanwhile, my operation would be removed from the NSOperationQueue and the block wouldn't be called.

What leads you to believe this. A block is a closure, a self-contained block of code. It does not rely on the existence of some other object (the NSOperation in this case) in order to exist. You might want it to rely on that other object, but that's up to you to enforce. Ideally, I'd make getStufSuccess:failure: synchronous. If you can't you can use an NSCondition or call NSRunLoop methods to block the thread cheaply until it's done.

You also need to consider thread safety here. Your problem might not have to do with the operation going away, but your block doing something that isn't thread-safe.

score 0 · Answer 2 · answered Mar 31 '12 at 00:50

0

If your -getStuffSuccess:failure doesn't block the thread (i.e. the method is asynchronous), then your -main will complete and your operationQueue may deallocate your operation before the success or failure blocks are called. You can block the thread by adding a:

while(notProcessed){
    sleep(0.1);
    //Make sure your success and failure functions update notProcessed BOOL
}

so that main never completes before you've had a chance to call the closures. Or just use a synchronous method. This is generally fine because you won't be on the UI thread anyways.

answered Mar 31 '12 at 00:50

waggles

2,804
1
15
16

In this situation you need to use a concurrent operation (with a -start method, not a -main, and some other KVO things... see my response above) – jsd Mar 31 '12 at 20:29
Cool, thanks. jsd's answer provides a much more correct, non-hackish solution if this was the problem. Also: [asynchronous-methods-in-nsoperation](http://stackoverflow.com/questions/1596160/asynchronous-methods-in-nsoperation) – waggles Apr 03 '12 at 01:44

score 0 · Accepted Answer · answered Mar 31 '12 at 20:27

0

Since getStuffSuccess:failure is asynchronous, you need to use a concurrent operation. Here is a helpful blog post: http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/

answered Mar 31 '12 at 20:27

jsd

7,673
5
27
47

Method with blocks inside NSOperation - how does it work?

3 Answers3