Rosyna wrote on Monday, March 12, 2007:
>Ack, at 3/12/07, James Bucanek said:
>
>> >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.
Well, I don't use any of those in my very (very) simple application. Like I said, this application isn't much more than a glorified server for -setStringValue: so that a secure helper task can display its progress.
>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.
That has not been my problem.
>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.
Actually, it turns out to be really easy. And if you send DO messages from multiple threads, you have to assume that any thread can receive a DO message from a object vended on another thread. I've had to deal with this extensively in some of my server code. Here's what happens:
C = Client computer
S = Server
A = Thread A in server
B = Thread B in server
S1 = Object in server vended to C
C1 = Object in C passed to S
S starts threads A and B
C connects to S
S vends S1 to C
C send C1 to S via a message sent to S1
Thread A goes back to waiting
Thread B sends a message to C1
While B is waiting for a reply, C sends another message to S1
The message sent to S1 may execute on either threads A or B
What happens is that when B sends a message to an object, it spontaneously creates a run loop to receive the results of the message. While it's waiting, it will randomly intercept and dispatch any incoming messages send by C. Essentially, you have no way of controlling which waiting run loop will pluck out the next DO message and dispatch it. Note that this is probably a feature. :)
So this kind of thing is very common in multi-threaded DO applications that are sending asynchronous messages in both directions. But it shouldn’t ever happen in a single thread/run-loop environment.
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
