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 protected]> 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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
