Re: Notifications on main thread
Re: Notifications on main thread
- Subject: Re: Notifications on main thread
- From: Jonny Taylor <email@hidden>
- Date: Tue, 2 Nov 2010 18:07:10 +0000
Thanks for your reply James. That is what I would have assumed, and your -performSelectorOnMainThread is equivalent to my:
[NSOperationQueue mainQueue] addOperationWithBlock
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);
You and I are talking about calling:
[NSNotificationQueue defaultQueue] enqueueNotification...
from a selector or block that has been run on the main thread. The release notes appear to be going out of their way to state that doing this does NOT guarantee anything about which thread the notification callbacks will be run on, therefore implying that posting the notification on the main thread may not achieve what we had hoped.
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.
This makes me very uneasy!
Jonny
On 2 Nov 2010, at 15:21, James Bucanek wrote:
> Jonny Taylor <mailto:email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden