OK, I think I have managed to read the release note again using your interpretation, but I think I will follow your suggestion of filing a documentation enhancement request.
However, I think their second bullet point "Notifications posted through a queue might not ever be posted" is still an important one though, that might be enough to rightly put people off using notifications for anything important. I would interpret their explanation as being compatible with a case where for example a notification posted just before a modal loop ended would evaporate into the aether (even though it was posted through the main thread's default queue and the main thread is still running). That sort of thing should probably put me off using them for many of the things I currently do... On 2 Nov 2010, at 18:44, James Bucanek wrote: > Jonny Taylor <mailto:j.m.tay...@durham.ac.uk> wrote (Tuesday, November 2, > 2010 11:07 AM -0000): > >> Empirically that does seem to behave in a common sense manner. However, if we >> examine the wording of the release note I believe it is explicitly stating >> that this should NOT be relied on - i.e. posting a notification from a >> selector on the main thread does not guarantee that the registered >> notification callbacks will be executed on the main thread. The release notes >> state [my emphasis]: >>> Notifications can be posted by any given queue ON A DIFFERENT THREAD THAN >>> THE THREAD THE QUEUE IS A DEFAULT QUEUE FOR (when a queue is >> a default queue for some thread); > > ... > >> I agree with you that the approach you and I are talking about seems to work >> in practice, and certainly seems like a logical approach, but somebody at >> Apple seems to have taken the time to write an obscure release note >> specifically discouraging such an approach. > > Jonny, > > I think you're reading too much into the statement made in the release nodes. > If we assume that notifications are posted from the thread they are > _enqueued_ from, then the wording of the release note is absolutely correct. > It's a warning for those who would (rightfully, in my mind) assume that the > notification would be posted in the thread associated with the run loop that > the queue is connected to. > > What this footnote does NOT say is "Warning, your notification will be posted > via some random thread that you have no control over," which is how I think > some people are interpreting it. > > I think this is because the release note is written from the perceptive of > the queue. From the queue's perspective, notifications could be executed from > any thread. But from the perspective of the enqueuer, the notification is > always posted in its thread. > > I think it's clear from the document that notifications > ARE posted from the thread that ENQUEUES the notification, > NOT the thread that OWNS the queue's run loop. > > If you don't think that the documentation is clear about this point, file a > documentation enhancement request. I've filed requests like this in the past, > and have been almost universally reworded with improved documentation. > > James > -- > James Bucanek > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
