Jonny Taylor <mailto:j.m.tay...@durham.ac.uk> wrote (Wednesday,
November 3, 2010 9:05 AM -0000):
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...
Jonny,
I (finally!) found the NSNotficationQueue Warning that you're
referring to.
Reading it, I can see where the panic and confusion comes from.
But I don't think the situation is as dire as some are making
out. Sure, there are some VW-sized open manholes to avoid, or at
least some things to consider when using notification queues.
But I don't see many as show stoppers for the vast majority of solutions.
Here's what the warning is (basically) saying: Notifications are
queued and dequeued (i.e. posted) by run loops. Thus, in certain
circumstances, the processing and posting of notifications may
happen at unpredictable times on unpredictable threads.
But "unpredictable under certain circumstances" doesn't mean
"random". What the release note is saying is that it's the run
loop of the current thread (the one that sends
-[NSNotificationQueue enqueueNotification:...]) is the one
that's going to process the enqueue notification message.
This has a number of ramifications, although the release note
uses overly scary language (IMHO):
1) The run loop of the current thread is the one that's going to
process the enqueue request.
1.a) The run loop must be running, and keep running, until the
enqueue request is processed.
1.b) The run loop must be running in the correct mode for the
enqueue request to be processed.
2) Enqueuing a notification may cause coalescing, or not. That
means when the enqueued notification is processed, there may be
other notifications before it that need to be posted first. If
there are, those will be posted on the thread of the run loop
that's processing the enqueued notification.
So this explains ALL of the things that the release note worries
about: Notification never been posted, notifications being
posted on a different thread, notifications being posted by a
run loop of a thread different than the default for that thread,
not being able to guarantee the thread a notification will be
posted on, and so on.
But what the release note doesn't say is that almost all of
these problems are problem only when you have multiple threads
enqueuing notifications to a single notification queue. If all
of the notifications come from a single thread, and that single
thread has a running run loop (in the correct mode), none of
these warnings apply. So if you enqueue all of your
notifications on the main thread, everything gets enqueued,
dequeued, and posted on the main thread. Easy peasy.
The other situation that's perfectly manageable is multiple
threads enqueuing notifications, where each thread has a run
loop (running the appropriate mode). The solution is to simply
NOT assume the thread the notification will be posted on. Write
your code so that the notification methods are thread safe and
you're done.
I hope that helps.
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
