On Sep 16, 2009, at 8:35 AM, Jerry Krinock wrote:
From NSNotificationQueue Documentation:
NSPostASAP [...]
NSPostWhenIdle [...]
NSPostNow [...]
Since a run loop is a closed loop, I always get confused about what
is the "end", and when it is idle. I guess the "notification
callout" is the part in the run loop when notification inputs are
processed and sent, but I'm not sure when that is, in relation to
"coalescing".
Have you read this?
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Notifications/Articles/NotificationQueues.html
Coalescing happens when notifications are enqueued. I'm not sure what
you mean regarding "when notification inputs are processed and
sent ... in relation to 'coalescing'".
In actual practice, I'm a dummy and think like this:
1. I have a hypothesis that a notification is getting posted too
early relative to other stuff, so I want to delay it and see if
things work better.
2. I have a hypothesis that a notification is getting posted too
late relative to other stuff, so I want to make it happen earlier
and see if things work better.
That strikes me as flailing. If you need things to happen in a
certain order, then ensure they happen in that order using various
deterministic mechanisms. I think posting notifications
asynchronously is not what you want. Or, perhaps, you shouldn't be
doing "other stuff" with indeterminate timing relative to the
notification. Maybe it should be done _in response to_ the
notification, if it has to happen before or after whatever you're
currently doing in response to the notification?
Also, why are you (apparently) guessing about when things are
happening? If nothing else, just put logging statements in and see in
what order things are happening.
In my experience, it seems that the order of the above three styles
from earliest to latest, is:
1. NSPostNow
2. NSPostASAP
3. NSPostWhenIdle
Is that true?
It seems straightforward from their descriptions that that is true,
but it seems besides the point. The posting style is not meant as a
means for you to precisely time when notifications are posted. You
couldn't do that, anyway, since you can't know what other runloop
sources or timers are waiting to be processed.
Rather, you should just follow logic like:
Do I need the notification to be posted synchronously (before the call
to the notification queue or center returns to me)?
If yes, do I need to remove any similar notifications that may have
been previously queued?
If yes, use NSPostNow
If no, use NSPostNow or -[NSNotificationCenter
postNotification...]
If no, can/should the posting wait until the runloop is idle?
If yes, use NSPostWhenIdle
If no, use NSPostASAP
The fact that you aren't given precise documentation as to timing is,
I think, a deliberate aspect of the design. That's not what they're
for. And I can't really think why you need or want that. Why do you
think you need or want that?
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
