On May 14, 2011, at 11:46 AM, Jonathan Taylor wrote: > The problem can be summarised as: in spite of having a backlog of > notifications building up on the main thread, NSPostWhenIdle-qualified > notifications do seem to be making it through. This is causing me problems > because this idle work is swallowing up main thread time, making the backlog > even worse! I am trying to understand why this is happening and whether I can > do anything to alleviate the situation.
I suspect you have assumed things about NSPostWhenIdle and NSPostASAP which just aren't true. In particular, you think that the former is "prioritized" lower than the latter. However, they just indicate different points during a run loop's execution when the notifications are delivered. Notifications queued with NSPostWhenIdle are posted when the run loop is idle -- when it would otherwise put the thread to sleep waiting for something to happen. Those queued with NSPostASAP are posted after an input source or timer is serviced (when it's handling function or method returns). If no input sources or timers are firing, then notifications posted with NSPostASAP may not fire soon. Unfortunately, operations being queued or run in the main queue don't count, it would seem. At least, I think that's what's happening. You may also be running into this issue, somehow: <https://devforums.apple.com/message/111998#111998>. NSOperationQueue's +mainQueue presumably uses dispatch_get_main_queue() under the hood. One obvious improvement to your scheme is, since Function C should not do anything unless and until Function B has processed a new frame image, post its notification (notification 2) from Function B, not Function A. (Or otherwise arrange for Function C to be triggered by Function B's completion.) Still, that won't help if Function B is not being called as often as you expect because NSPostASAP doesn't work like you thought. I suspect that it is only being called when something else tickles the run loop, like user events. I wonder if you click-and-hold in your window (not necessarily on a button or any active control) and just keep dragging the mouse back and forth, if that helps keep the backlog clear. (Simple mouse moves without the mouse button don't send events unless your window has specifically subscribed to them using NSTrackingArea or -setAcceptsMouseMovedEvents:.) Regards, Ken _______________________________________________ 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
