mikeash.com pyblog/friday-qa-2010-01-08-nsnotificationqueue.html comments

Hano - 2014-08-01 17:29:08

Fri, 01 Aug 2014 17:29:08 GMT

I'm also a bit curious if these warning still persists. How about iOS?

folex - 2014-03-11 14:39:27

Tue, 11 Mar 2014 14:39:27 GMT

Are problems in the warning still persist?

Hoang Toan - 2012-04-11 04:52:59

Wed, 11 Apr 2012 04:52:59 GMT

Great post ! It's useful for me. Thanks so much.

mikeash - 2010-02-14 21:51:15

Sun, 14 Feb 2010 21:51:15 GMT

Well, I don't think updating the class documentation would be enough here, although it certainly would have been better. If those warnings are correct then the class simply cannot be used safely. If that's the case, and they don't fix it, then they need to officially deprecate it to indicate that it's bad and you shouldn't touch it.

Jeremy W. Sherman - 2010-02-14 19:53:01

Sun, 14 Feb 2010 19:53:01 GMT

"Apple should have either deprecated the class or fixed it. Hiding the problem away in a release note is completely ridiculous."

Far too much useful information is hidden away in release notes and never makes it into the permanent documentation. At the very least, they could have updated the NSNotificationQueue class reference documentation to include the warning.

The practical upshot of this is that the release notes are essential reading if you want to learn the fine and ugly details of the frameworks as they stand, rather than as they were documented four or five years ago. This, unfortunately, significantly reduces the utility of the documentation that you can readily access from Xcode: essential information is no longer just an Option-double-click away.

mikeash - 2010-02-13 22:16:38

Sat, 13 Feb 2010 22:16:38 GMT

Well that's some Grade A BS right there. The described behavior makes the class completely useless, and therefore can only be considered a bug, even though it may align with an extremely legalistic and pathological reading of the documentation in question. Apple should have either deprecated the class or fixed it. Hiding the problem away in a release note is completely ridiculous.

Jeremy W. Sherman - 2010-02-13 19:25:21

Sat, 13 Feb 2010 19:25:21 GMT

You might want to be careful of NSNotificationQueue. See the "Using NSNotificationQueue Warning" section in the Foundation release notes <URL:http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html&;gt;. I've taken the liberty of quoting the passage in its entirety:

Using NSNotificationQueue Warning (New since WWDC 2009)
NSNotificationQueue is an API and mechanism related to run loops (NSRunLoop), and the running of run loops. In particular, posting of notifications via the notification queue is driven by the running of its associated run loop. However, there is no definition for what run loop a notification queue uses, and there is no way for a client to configure that. In fact, any given notification queue might be "tickled" into posting by nearly any run loop and different ones at different times (and given that enqueued notifications are also mode-specific, what mode(s) the run loop(s) are running in any any given time also come into play). Further, although each notification queue is "thread-specific" (see the +defaultQueue documentation), there has never been any relationship between that thread and the run loop used by a notification queue. This is all more and more problematic as more and more things move to happening on different and new threads.

The practical upshot is:
- Notifications posted through a queue might not be posted in any particular "timely" fashion;
- Notifications posted through a queue might not ever be posted (the run loop of the thread that the queue chose to ask to poke it might not be run again; for example, the thread of that run loop might exit and the notification queue discarded);
- Notifications can be posted by any given queue on a different thread than the thread the queue is the default queue for (when a queue is a default queue for some thread);
- Notifications can be posted by any given queue on different threads over time;
- There is no necessary/guaranteed relationship between the thread(s) on which notifications are enqueued and those on which the notifications eventually get posted (delivered) for any notification queue

This is true for all releases of Mac OS X. Foundation and AppKit do not use NSNotificationQueue themselves, partly for these reasons.

mikeash - 2010-01-12 06:21:45

Tue, 12 Jan 2010 06:21:45 GMT

It would be a great topic if it weren't for the fact that I don't know it well, and its great complexity doesn't translate to being all that interesting in terms of how it works. (Obviously it's interesting in terms of producing extremely useful results.) Thanks for the suggestion, though, I'll make a note of it in case I change my mind later.

Colin Barrett - 2010-01-10 21:50:16

Sun, 10 Jan 2010 21:50:16 GMT

Cocoa's text system is complicated, powerful and relatively poorly understood. Sounds like a great topic for Friday Q&A to me.

mikeash - 2010-01-10 06:10:33

Sun, 10 Jan 2010 06:10:33 GMT

It would be pretty trivial to add a category to NSNotificationCenter to add coalescing/delayed methods that just call through to NSNotificationQueue, if you wanted to. Of course, if your grip is that NSNotificationQueue is hard to discover, that doesn't help at all.

Frédéric Testuz - 2010-01-09 08:01:57

Sat, 09 Jan 2010 08:01:57 GMT

I used NSNotificationQueue some years ago. I had never used thread, had to process a large amount of data and wanted to keep my app responsive. But at this time, I didn't have the time to learn about threading issues.

So I break my code in small portions. At the end of a portion I sent a notification with NSPostWhenIdle. When the notification was post I proceed with the next portion. It worked very well.

John McLaughlin - 2010-01-09 06:12:47

Sat, 09 Jan 2010 06:12:47 GMT

Great Post -- Many a time I've wondered how to execute something lazily (and I just don't mean my personal life!)

I sort of wish they hadn't split NSNotification and NSNotificationQueue but instead provided a single interface and allow flags or calling semantics.

I'm sure I'll use soon!

mikeash - 2010-01-09 03:59:16

Sat, 09 Jan 2010 03:59:16 GMT

Yes, I've found -performSelectorOnMainThread: to be troublesome when used in a tight loop. It operates at a high priority and can cause the app to become unresponsive if you aren't careful.

For #3, from the docs:

 A notification queue maintains notifications (instances of NSNotification) generally in a first in first out (FIFO) order.

That word "generally" is a bit disconcerting, but I think that refers to the fact that e.g. NSPostASAP notifications will happen before NSPostWhenIdle even if the NSPostASAP happened later.

I have not tested it, though, so it could be way wrong.

Sarah Holbrook - 2010-01-08 18:26:17

Fri, 08 Jan 2010 18:26:17 GMT

Mike, very valid points. Posting to the main thread (#2 in your followup) is really helpful especially when the intent is for the UI/controller classes to act on the notification. It's another one to be careful with though; I've seen it lead to performance problems that aren't obvious when sampling.

Adding one more notification (#3) seems like it could work. I'm curious if anyone's tested it. If there were another "idle" notification is it guaranteed to send first? I haven't verified if the queue is mostly in name or whether it's truly FIFO with delayed notifications.

Anonymous - 2010-01-08 17:50:15

Fri, 08 Jan 2010 17:50:15 GMT

Interesting you mention this class, I only noticed it for the first time a month ago when I was redoing The Gist (OSS Twitter app) to no longer use bindings to update other observers that new tweets were imported into the app from Twitter. This class makes perfect sense in this context because tweets can be imported individually or in large, indeterminately-sized batches.

mikeash - 2010-01-08 15:58:54

Fri, 08 Jan 2010 15:58:54 GMT

Daniel Hedrick: Yes, they would be in the slider's target. sliderMoved: would be set as the target of the slider. You'd also need some code somewhere (in the init method, probably) to add the object as an observer for SliderDoneMovingNotification with sliderDoneMoving: as the observation method. There's no automatic hookup for that sort of thing, unfortunately.

Sarah Holbrook: The problem of secondary threads with finite lifetimes is an interesting one. I can see a few reasonable solutions:

1) Only use NSNotificationQueue for things that can withstand not being delivered.

2) Ship the queued notifications to the main thread, or to another thread which lives forever.

3) When exiting the thread, add another notification with NSPostWhenIdle, then spin the runloop until it fires. This should mean all other pending notifications have fired as well... assuming none of the observers use NSNotificationQueue!

Definitely takes some added thought and work for this case, though.

Speaking of NSOperation, using NSNotificationQueue from an NSOperationQueue or a GCD queue could be a really good way to run into trouble.

Sarah Holbrook - 2010-01-08 15:45:08

Fri, 08 Jan 2010 15:45:08 GMT

This is really helpful when running on the main event loop.

For any thread that has a finite life, be careful when using anything but NSPostNow. The delayed notifications are not guaranteed to be sent. I don't know of an elegant solution; one workaround is to give the current runloop an extra workout before the thread dies. In practice I've seen delayed notifications on a background thread lead to many bugs when not managed carefully.

It depends on what you're trying to acheive but NSOperation dependencies offer an alternate for "do this afterwards" when you're off the event loop (but need to be configured before the initial work begins).

Dan Leehr - 2010-01-08 15:38:55

Fri, 08 Jan 2010 15:38:55 GMT

Great post, an under-covered subject that had my gears turning the whole time. I use notifications very heavily in my iPhone app and I can think of several places where I should be using notification queues to coalesce them.
Also, this solidifies the run loop concepts even more, so bonus!

Daniel Hedrick - 2010-01-08 15:27:31

Fri, 08 Jan 2010 15:27:31 GMT

Quick question about these two methods you're defining (mostly about semantics, I guess)...

Would these be declared in the controller that is the target of the slider?

I'm assuming so, but I'm a little rusty on my Cocoa and not in front of a Mac to test (for shame!).

mikeash - 2010-01-08 15:10:50

Fri, 08 Jan 2010 15:10:50 GMT

I wondered many times while writing this post whether other people would find it interesting, or if I was the only one who missed the significance of this class for so long. Looks like I was right to go ahead!

If you can find any more weird, obscure, useful classes to expound upon, let me know!

Jonathan Wight - 2010-01-08 14:18:35

Fri, 08 Jan 2010 14:18:35 GMT

Crap. I've written code that basically does everything that NSNotificationQueue is doing. I should have just used NSNotificationQueue - now I know to use it in future.

It's definitely one of those classes that you look at in the docs and think "that's useful, wonder what I should use it for", and then you promptly forget about it.

More topics like this please! (And the NSRunloop post was great too). I'll scan through Foundation.framework and look for other obscure but useful classes.