Re: NSNotificationQueue & NSOperationQueue thread death
Re: NSNotificationQueue & NSOperationQueue thread death
- Subject: Re: NSNotificationQueue & NSOperationQueue thread death
- From: Michael Ash <email@hidden>
- Date: Wed, 6 May 2009 00:24:34 -0400
On Tue, May 5, 2009 at 11:44 PM, Eric Hermanson <email@hidden> 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 (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