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: Oleg Krupnov <email@hidden>
- Date: Wed, 29 Sep 2010 13:16:31 +0300
Hi Ken,
Now I see. I hardly find words to thank you for your patience! :)
There's been indeed a misunderstanding. I imagined mistakenly that
there could be many "connection points" on the server, one connection
point per thread, and each such connection point could vend a
different object of different type. So I was looking for a way to pass
"address" of this new connection point (like the registered name for
the main one) to the client thread, so that it could call a method
similar to rootProxyForConnectionWithRegisteredName on it.
Now I see that the correct picture is the following. There is only one
connection point, and there is only one root vended object in the
server. I need only to make sure that each client thread uses a
different connection object, though all connections use the same
connection point and send port on server (addressed by its single
registered name). In other words, this new connection is like a
parallel channel to the same root vended object. So when I call
rootProxy on the new connection on client, I obtain the same root
proxy (not the per-thread proxy that I initially thought of). Then I
ask this root proxy to take the current connection and detach it to a
new thread. Objects and threads are fully orthogonal.
Of course, I've read all docs, but I found them quite scarce and even
confusing at times. Only with your help, and with some knowledge of
sockets I have, I went down to the basics and became able to
understand how it works under the hood. For example, the docs say
nothing about the notion of connection points as opposed to child
connections. It calls everything a "NSConnection" and this was my
source of confusion.
There is only one problem left: logs show that although I obtain the
root proxy for the new connection and call a worker method on it in
client, the server still uses the main thread to respond, instead of
the newly created connection's thread. More experiment shows that when
there is already a busy server thread, then the server uses the new
thread, but when there are no other threads, the main thread is used.
Is it a kind of optimization the framework does, or is it my bug? I'd
like that each client thread only worked with its dedicated server
thread and did not mess with the server's main thread.
Thank you again,
Oleg.
On Wed, Sep 29, 2010 at 3:26 AM, Ken Thomases <email@hidden> wrote:
> On Sep 28, 2010, at 1:23 PM, Oleg Krupnov wrote:
>
>> So, let's assume I create the connection in this way:
>>
>> NSConnection* connection = [NSConnection connectionWithReceivePort:nil
>> sendPort:[[NSMachBootstrapServer sharedInstance] portForName:@"foo"]];
>>
>> or even
>>
>> NSConnection* connection = [NSConnection
>> connectionWithReceivePort:[NSMachPort port] sendPort:[NSMachPort
>> port]];
>>
>> Then I vend the object:
>>
>> [connection setRootObject:serverObject];
>>
>> And finally launch it in a separate thread:
>>
>> [connection runInNewThread];
>>
>> But how do I pass this connection back to client so that I could call
>> -rootProxy on it?
>
> You don't. Please reread what I wrote. My last email was largely about how the client creates its connection. You've misunderstood it to be about how the server creates it. (The above approaches wouldn't even work for a server.)
>
> Servers don't create connections to clients. Clients create connections to servers.
>
> A server only explicitly creates a single NSConnection instance. This isn't a connection so much as a "connection point" -- a place where clients can connect to.
>
> Then, clients create connections to the server. In response, in the server, the frameworks implicitly create new NSConnection instances for each client connection. Once again, this is clearly illustrated in the documentation on Distributed Objects. Have you read it?
> <http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/DistrObjects/Concepts/connections.html>
>
> We've already discussed how and when the server tells the newly-created connections to run in a separate thread.
>
> The only complication is that, because your clients are attempting to make multiple connections from the same process, and because the frameworks try to reuse connections within a process, you have to take some minor extra precautions to make sure you are getting separate, independent connections to the server. I have told you how to do that.
>
>> That was actually the original question in the
>> subject of this mail :)
>
> Not as I understood it. And if it was, then you have a fundamental misunderstanding about how connections work. Again: servers don't create connections to clients; clients create connections to servers.
>
>> The other question I've got is how do I exit the newly created thread
>> when its job is done?
>
> It should exit when the connection from the client closes. It's possible that the server will have to explicitly -invalidate the connection in response to a sign-off message from the client.
>
> 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