Also, CoreAudio creates threads with runloops. This thread can be
created, for example, this *may* be created if your application ever
beeps, or if anything else is pumped through CoreAudio.
Oddly, you can actually see the source code to the thread in question
at /Developer/Examples/CoreAudio/PublicUtility.
In this specific example, the backtrace/sample from James showed the
CAPThread was the one creating the run loop.
This thread is created irregardless if whether you use CoreAudio
itself. The system may/will create the thread as needed for you.
However, I still don't believe this thread is responsible for this
issue, since the thread itself isn't doing anything.
Ack, at 3/12/07, Jim Correia said:
On Mar 12, 2007, at 7:33 PM, James Bucanek wrote:
Especially if you are cocoa, you can count on having threads that
aren't yours running with their own runloops in the background.
I've never seen this. But again, I want to point out that there's a
significant difference between a nested run loop in the main thread
(modal dialogs and mouse drag routines do this all the time) and a
separate run loop in it's own thread.
Apple frameworks can and do spawn threads which use their own
runloop. Foundation's url loading classes are an example of this.
If any runloop on a secondary thread can "steal" DO messages and
have the code run in the context of the "wrong" thread, please show
us a sample app which demonstrates the problem.
--
Sincerely,
Rosyna Keller
Technical Support/Carbon troll/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
