On Tue, May 5, 2009 at 11:44 PM, Eric Hermanson <zmons...@mac.com> wrote: > > I'll also ask a follow-up question, and that is, if one puts an > NSNotification onto the thread's NSNotificationQueue in a method called by > performSelectorInBackground..., then is it safe to assume this notification > will probably never get sent because the thread spawned automatically by > performSelectorInBackground would have exited before that thread's > NSNotificationQueue got a chance to deliver its notifications?
To answer this and the NSOperationQueue question, first ask this question: when you post a notification onto your thread's NSNotificationQueue, when, precisely does it get delivered? The answer depends, obviously, on how you post it. If you post with NSPostNow, the notification is delivered immediately. If you post with NSPostASAP, the notification is delivered when you return back to the runloop. If you post with NSPostWhenIdle, then it's like NSPostASAP, except it waits until the runloop is not busy with anything else. The semantics for NSPostNow in background threads and NSOperationQueues should be obvious. For the others, notice how they both assume that you're being called from a runloop. Background threads, whether directly managed by you or indirectly created by NSOperationQueue, do not use a runloop by default. So if you do not create and use one yourself, then you can be pretty confident that notifications posted in that way will never be delivered. Mike _______________________________________________ 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
