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 17:57:37 +0300
Hi Ken,
> I'm not sure exactly what's happening. It sounds like the connection's ports are still scheduled in the main thread's run loop as well as the new thread's run loop. When a request arrives and both run loops are idle, it's effectively arbitrary which one will handle the request. I would have thought that -runInNewThread would do this implicitly, but you may have to use -[NSConnection removeRunLoop:[NSRunLoop currentRunLoop]] to remove the connection's ports from the run loop of the main thread (or whichever thread the check-in message is handled by).
I tried -[NSConnection removeRunLoop:[NSRunLoop currentRunLoop]], but
it doesn't seem to change anything.
Well, I could live with it, because the server already works as
multi-threaded, but the problem is that the new thread that is
spawned, is not released if the request is handled in the main thread,
when I call -invalidate on the connection. And there does not seem a
way to get the thread created by runInNewThread to exit it manually,
or is there?
Thanks,
Oleg.
On Wed, Sep 29, 2010 at 2:22 PM, Ken Thomases <email@hidden> wrote:
> Hi Oleg,
>
> On Sep 29, 2010, at 5:16 AM, Oleg Krupnov wrote:
>
>> Now I see. I hardly find words to thank you for your patience! :)
>
> You're welcome. I'm glad I could help.
>
>
>> 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 the server, it is the receive port which is registered under a name. The server "receives" connections from clients on that port. (Actually, reading the docs for -initWithReceivePort:sendPort:, the server's connection point typically uses the same port for receive and send.)
>
>> 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).
>
> You should receive a different proxy to the same root object. (The root proxy is an NSDistantObject that is specific to the connection. So, a different connection implies a different proxy object.)
>
> But you are correct that the design has a single root object in the server, not multiple root objects, one for each client connection.
>
>> Then I
>> ask this root proxy to take the current connection and detach it to a
>> new thread. Objects and threads are fully orthogonal.
>
> Well, the client shouldn't be aware that its check-in message has the result of spawning a new thread in the server. The check-in message should just be a way for the client to make the server aware of it, and to initiate service for it (whatever "service" means in your application). The server could be designed either way, with a separate thread per client connection or all handled by one thread.
>
> If having a single root object feels cumbersome, the root object could be turned into just a factory for per-client service objects. So, the client checks in and asks the single root object for a new object which will serve just it (that specific client; I consider each thread within the client process to be a separate "client" in your design). The server creates a new object to satisfy that request, and that new object would be initialized with whatever state is specific to that client. It would also happen to spin off a separate thread to handle communications with that client, but that's an implementation detail.
>
>
>> 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.
>
> OK. I can definitely see how the docs can be confusing or less than thorough. I recommend that you file requests for enhancements to anything you didn't understand.
>
>> 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.
>
> They do say "the connection labeled s is used to form new connections" and "A named connection rarely has a channel to any other NSConnection object (in Figure 1 and Figure 2 the named NSConnection objects are the circles labeled s). When a client contacts the server, a new pair of NSConnection objects is created specifically to handle communication between the two."
>
>
>> 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.
>
> I'm not sure exactly what's happening. It sounds like the connection's ports are still scheduled in the main thread's run loop as well as the new thread's run loop. When a request arrives and both run loops are idle, it's effectively arbitrary which one will handle the request. I would have thought that -runInNewThread would do this implicitly, but you may have to use -[NSConnection removeRunLoop:[NSRunLoop currentRunLoop]] to remove the connection's ports from the run loop of the main thread (or whichever thread the check-in message is handled by).
>
> Cheers,
> 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