Dear Ken, According to your reply, I think the threads I created explicitly caused the problem? So asynchronous notification cannot be used in this case?
Thanks so much! Best, Bing On Mon, Jun 6, 2011 at 2:34 AM, Ken Thomases <[email protected]> wrote: > On Jun 5, 2011, at 11:20 AM, Bing Li wrote: > > > My system is a Cocoa Application. I know RunLoop is created automatically > in > > such a project. So asynchronous notification should work. > > A Cocoa application does automatically run the run loop of the main thread, > if you allow it. So, I have a couple of questions: > > 1) Are you queuing these notifications on the main thread? > > 2) Are you allowing the flow of execution to return back to the framework, > thus allowing it to run the run loop? > > Another point: it was recently discussed on this list that the NSPostASAP > posting style has a very specific meaning. Notifications queued with that > style are delivered immediately after a run loop source or timer has been > serviced. If no run loop sources or timers are being serviced for a while, > then they may be delayed indefinitely. NSNotificationQueue predates > NSOperationQueue and GCD. Back then, just about the only way to run code on > the main thread was while servicing a run loop source or timer, so an > NSPostASAP notification would in fact be delivered immediately after you let > execution return to the framework. However, now it's possible to run an > operation or a block on the main thread, and I don't think those count as > run loop sources or timers. > > Regards, > Ken > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
