>Note that there a MANY APIs in Mac OS X that spawn their own run
loops/threads. DiscRecording, the Cocoa heartbeat thread.
AppleScript, and countless others I can't remember. Future versions
of Mac OS X will have APIs which no doubt spawn even more threads and
even more run loops.
Additional thread, sure. Nested run loops, sure. But separate run
loops? Run loops that steal distributed object messages? I've yet to
run across any framework that does this (and certainly none of the
ones I'm using this tiny little background application), although
I'd be happen to shown where I'm wrong.
Yes, separate run loops. Like mentioned, NSURLConnection and a bunch
of others (including Disc Recording). In fact, I'd say it's more
unusual for new threads to be created without a new run loop.
Nested run loops are what you REALLY have to worry about,. If you're
in a multithread app (which almost all cocoa apps in 10.4.x are, by
default) then it is possible to get nested run loops to lock the same
mutex and lock forever.
But as mentioned before, do you have an example of a new run loop
eating DO messages? I've never heard of this issue before.
>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.
Yes, I am talking about the latter.
--
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
