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 10:01:25 +0000
I'm reviving an old thread I posted (sorry, I can't remember who the people were who replied, but thanks again...) because I've just read something that rather alarmed me and would appreciate peoples comments.
An extract from the original thread is below, and here is the code I wrote based on those suggestions:
void SendNotificationOnMainThreadWithCoalescing(const NSString *notificationName, NSPostingStyle style, id obj)
{
NSNotification *myNotification = [NSNotification notificationWithName:notificationName object:obj];
[[NSOperationQueue mainQueue] addOperationWithBlock:
^{
[[NSNotificationQueue defaultQueue]
enqueueNotification:myNotification
postingStyle:style
coalesceMask:NSNotificationCoalescingOnName|NSNotificationCoalescingOnSender
forModes:[NSArray arrayWithObject:NSRunLoopCommonModes]];
}];
}
Now, what has alarmed me was reading the comments at the bottom of this article:
http://www.mikeash.com/pyblog/friday-qa-2010-01-08-nsnotificationqueue.html
which refers to the apple release notes ("Using NSNotificationQueue Warning"). If I am reading this right, it seems to be saying that there is no guarantee that the code I have written - or indeed any code at all - will cause the notification to execute on the main thread. As commented in the linked article, this surely makes the class utterly useless? If it does not necessarily run the notifications on the main thread this could lead to all sorts of concurrency issues, including much of AppKit, Carbon, etc etc. If true, the same problem applies to the sample code posted here:
http://www.cocoadev.com/index.pl?NotificationsAcrossThreads
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?
Thanks in advance
Jonny
>>>> My code works with a firewire video camera, and receives callbacks from the camera driver when a new video frame is received. Whenever this occurs, the UI needs to be updated to display the latest video frame. The UI update must run on the main thread - the callback thread is not a suitable place to do the update. Furthermore I would like to use NSPostWhenIdle and coalescing - if several new frames arrive between updates then we only need to draw the most recent.
>>> [...]
>>>> - I could try acquiring the NSNotificationQueue for the main thread, but there does not appear to be a standard way of doing that. I have seen this suggested as a strategy elsewhere, but I think I have also read that one is not meant to post to queues other than that of the current thread (not sure why...).
>>> [...]
>>>> I feel there must be a simple way of doing what I want - can anybody advise?
>>>
>>> There is a way to do this. You need to set up the enqueue message in an NSInvocation, have it retain the arguments, and then call the invocation's -performSelectorOnMainThread:... method to invoke the invocation on the main thread. This works any time you need to call something on the main thread, but you need to set more than one argument, or the method has arguments that take primitives instead of objects.
>>
>> Note that if you're targeting 10.6 then you can do it MUCH more easily
>> by using blocks and either NSOperationQueue or GCD:
>>
>> // NSOpQ
>> [[NSOperationQueue mainQueue] addOperationWithBlock: ^{ /* post your
>> notification here */ }];
_______________________________________________
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