Jonny Taylor <mailto:j.m.tay...@durham.ac.uk> wrote (Tuesday,
November 2, 2010 3:01 AM -0000):
So, can anybody comment on all this? It seems like pretty bad news. Is this
what the release notes are saying, and if so, is there an alternative approach
that still lets me take advantage of the coalescing features of notification
queues?
I ran into this recently, and found it somewhat disconcerting,
but I think the situation is simpler than described in the
discussion link that you post.
It's my experience that queued notifications are posted _on the
thread that enqueued the notification_.
See, it's not that complicated. It does seem to be independent
of the notification queue and the notification center.
Privately, I suspect that -[NSNotificationQueue
enqueueNotification:...] works by pushing something to the run
loop of the currently running thread, so it's this thread that
processes the enqueue request, which implies which thread is
running when the notification is dispatched. But that's entirely speculation.
Since -enqueueNotification:... has no parameter for specifying
which run loop is used, the run loop is always implied by the
current thread. My solution, in the situation where a background
thread needs to queue a notification that will run on the main
thread (or any thread), is to encapsulating the code that
enqueues the notification in method and make sure that runs on
the main thread via -performSelectorOnMainThread:, or something similar.
--
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
