Re: NSNotificationQueue & NSOperationQueue thread death
Re: NSNotificationQueue & NSOperationQueue thread death
- Subject: Re: NSNotificationQueue & NSOperationQueue thread death
- From: Ken Thomases <email@hidden>
- Date: Wed, 6 May 2009 12:29:01 -0500
On May 6, 2009, at 12:03 PM, Jonathon Kuo wrote:
On May 6, 2009, at 9:03 AM, Michael Ash wrote:
It is correct that every thread conceptually has exactly one runloop.
I say "conceptually" because in fact they are created on demand.
So if a thread has no need to pay attention to asynchronous events
(timers, input sources, etc) but is only in existence to run its own
functional code (say, calculate a square root), it has no need to
have a runloop running. It can simply execute in more or less linear
fashion and exit.
Correct.
A thread starts out with no runloop, but as soon something tries to
interact with that thread's runloop, one is created for it.
Here's where I don't quite follow. If my thread doesn't set up and
explicitly run its runloop, won't async events just get ignored
because the thread has no code to receive/process them?
If you're referring to Cocoa and CoreFoundation async events, then
pretty much, yes. Sounds like you follow just fine. ;)
The framework may sometimes run the run loop on your behalf. For
example, -[NSTask waitUntilExit].
And, of course, one could always replicate functionality similar to
that of run loops using the base POSIX/BSD APIs, like select, poll,
kqueue, or the Mach message functions.
Cheers,
Ken
_______________________________________________
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