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: Tue, 28 Sep 2010 10:29:33 +0300
Thanks Ken,
I tried this:
> Your clients (each thread is a separate client, if you like) should be checking in with the server by invoking a specific method on the root proxy. They should be passing some object representing themselves to the server. On the server side, the check-in method will actually receive a proxy for the client's object. This will be an NSDistantObject. The server can invoke -connectionForProxy on it, then -runInNewThread on the connection.
And it seems to work. The client threads no longer block each other
when they need to request the server.
But let me ask a couple of questions, because I don't get how it works
and there might still be a problem in my code:
1. What happens when I call -connectionForProxy on the client proxy
object? Is a new connection created? Or the root vended object's
connection can be reused? In the latter case if I remove that
connection from the main run loop and call -runInNewThread, would the
root object's operation be broken?
2. I tried to launch two client threads simultaneously and pass
different objects to the check-in method, and I see that the
connection returned from -connectionForProxy is the same for the both
threads. Is it a problem? Won't the two threads somehow interfere?
AFAIR connections cannot be shared between different threads.
Here is my code of the check-in method of the root vended object on
the server side:
- (byref NSObject<IServerObject>*)createServerObjectForClientObject:(byref
NSObject*)clientObject
{
NSConnection* connection = [(NSDistantObject*)clientObject connectionForProxy];
[connection removeRunLoop:[NSRunLoop mainRunLoop]];
[connection runInNewThread];
// server object is a per-client-thread object on the server
side, not the root vended object
NSObject<IServerObject>* serverObject = [[[VendedServerObject alloc]
init] autorelease];
return serverObject;
}
Thanks!
Oleg.
On Tue, Sep 28, 2010 at 9:12 AM, Ken Thomases <email@hidden> wrote:
> On Sep 28, 2010, at 12:24 AM, Oleg Krupnov wrote:
>
>> My question is: is it possible to acquire the connection in another
>> way than using a name?
>
> Yes, of course. Have you looked at the NSConnection class reference, where it documents multiple methods for obtaining connection objects?
>
> First of all, your server already has multiple connection objects. The first connection is like a listen socket. As new clients connect, it accepts those and creates a new child NSConnection for each.
>
>
>> Why I want this: My client process has many threads, and the server
>> process must create a thread for each client thread.
>
> Your clients (each thread is a separate client, if you like) should be checking in with the server by invoking a specific method on the root proxy. They should be passing some object representing themselves to the server. On the server side, the check-in method will actually receive a proxy for the client's object. This will be an NSDistantObject. The server can invoke -connectionForProxy on it, then -runInNewThread on the connection.
>
> At least, I'm pretty sure that will do what you want. Another approach would be for the server to set a delegate on the main connection and, each time it is asked if it's OK to create a new connection for a new client (whether that new client is a separate process or just a separate thread), your delegate method can invoke -runInNewThread on the new connection.
>
> For a multi-threaded client which wants to have several connections to the same server, you may have to jump through a couple of hoops. NSConnection is pretty eager about reusing its instances if they match a new request. You may need to create the connection somewhat manually by creating the ports and then explicitly using +connectionWithReceivePort:sendPort: or -initWithReceivePort:sendPort:.
>
> 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