Tuesday, January 04, 2011

NSNotificationQueue, Coalescing and SIGABRT

So it's one of those days, your steaming along adding a feature and then bam, you hit a road block. Well here was mine.

I've come to love many cocoa API's over the last year. One i've been late to embrace is NSNotificationQueue. What can i say that hasn't already been made clear ... it's a queue for notification objects ... well almost it has one particular feature that makes it totally awesome, Coalescing.

Coalescing is useful for when you want to call a method multiple times but only have it execute it's action once every so often. Since i've started coding for iOS i've been a fan of simply calling [UITableView reloadData] to refresh my table views, it's simple concise and i don't have to worry about index paths etc. However if you are drawing complex cells, and you need to call this method while you process some data you really don't want to happen every single time, the user isn't playing COD, they just want to see their data, and not have it flick around. So in my UITableViewDataSource classes i do this ...


With the handler to the reloadNotification calling the actual reload method. This means that in one area of my app, where i am listening for NSManagedObjectContextObjectsDidChangeNotification (gotta love cocoa conciseness )the reload method gets called just once instead of 10+ times.

Awesome right ....

Well there is a problem, you might have noticed that enqueueNotification: takes a postingStyle. This calculates when in the duration of the run loop the queue will attempt to deliver your notification. Because i want my Run loop to be a free spirit and not care about what my crazy background threads were doing i would usually choose NSPostWhenIdle. Well i did till today.

The problem is the UITableView that this data source is assigned to can be dealloc'd at anytime, and while my dataSource is a good cocoa citizen and removes it's self as an observer before it is dealloc'd the notification has already been assigned it's target and is waiting till the run loop is idle ... read waiting till after my object has been dealloc'd. This of course means the the objective-c runtime attempts to call the reload method on dealloc'd object, and we all know what happens when that happens ... Well i thought i did. I code with NSZombieEnabled on, so in such a situation i expect to see a nice friendly message saying i've sent a message to an invalid object ... I got that message ... sometimes. Instead 9/10 times i got a big, fat, bold SIGABRT.

Oh, but you have stack traces ... um no. When crap happens in the objective-c runtime, you close your eyes and pray that they will go away, well thats what i do.

Anyways the solution was to ensure that notification was dispatched as quickly as possible, so NSPostNow was a much better fit. My professional($_$) opinion is that unless you have a long running object (ie the app delegate) or a singleton, never use the NSPostWhenIdle.

Conclusion

NSPostNow > NSPostWhenIdle
(9 out of 10 times)

No comments: