Re: Acquiring an NSConnection otherwise than by registered name?
Re: Acquiring an NSConnection otherwise than by registered name?
- Subject: Re: Acquiring an NSConnection otherwise than by registered name?
- From: Ken Thomases <email@hidden>
- Date: Thu, 30 Sep 2010 09:56:02 -0500
On Sep 30, 2010, at 6:21 AM, Oleg Krupnov wrote:
> I have checked the mailing archives and it seems that I am not alone
> with the problem that runInNewThread does not necessarily cause the
> request to be processed in the new thread. Some folks report that
> -removeRunLoop helped them, but my experiments show that
>
> 1. -removeRunLoop doesn't seem to have any reproducible effect. At
> times it works, other times not.
>
> 2. Even two subsequents calls via the same NSConnection (for which
> -removeRunLoop: and -runInNewThread was called) are not guaranteed to
> be handled in the same server thread. The server seems to freely pick
> any idle threads that from the ones that are currently running.
>
> 3. What is curious, the #2 also happens if instead of -runInNewThread,
> I create a thread manually via [NSThread
> detachNewThreadSelector:toTarget:withObject:] and [NSConnection
> addRunLoop:]. This is very weird -- the server utilizes any threads
> you create!
> 2. Can it happen because all connections on the server share the same
> receiving port, which is added to the main run loop?
That's my guess. I don't think it can pick _any_ thread, just any thread whose run loop has the shared receive port scheduled. I'm surprised it works that way, that the receive port is shared, but it is documented.
I'd be curious to know what happens if you use socket ports instead of Mach ports. It may be more efficient to use local-only Unix domain sockets instead of TCP/IP sockets, but either would be an interesting test. Judging from how a socket design would work if done "manually" with the BSD/POSIX API, the receive port (socket) would not be shared between the connection point and an accepted connection.
> 4. Because server threads are assigned to connection requests so
> arbitrary, it seems dangerous to manually quit any thread. It may be
> being used by the server at the moment at its discretion. This means
> effectively, that there is no way to exit unneeded threads on server,
> only to launch new.
This is incorrect. You should never terminate threads from the outside, you should only ever signal them to terminate themselves at a convenient point. Given that general guideline, this case is no different. If the thread is able to check your signal, then it's not in the middle of doing anything else and can safely exit.
> 1. There is [NSConnection multipleThreadsEnabled] that may be causing
> this behavior. Unfortunately, there is no way to turn it off, there is
> only -enableMultipleThreads, and by default it is on starting from
> 10.5. I wished there were disableMultipleThreads to try!
I don't think this is the culprit.
I repeat my recommendation that you open a developer technical support incident with Apple. You'll end up talking directly to the Apple engineers who implemented Distributed Objects and get their best advice for how to implement your design.
Regards,
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