Re: [NSConnection release] anxiety
Re: [NSConnection release] anxiety
- Subject: Re: [NSConnection release] anxiety
- From: James Bucanek <email@hidden>
- Date: Wed, 4 May 2005 17:25:03 -0700
Frank Midgley wrote on Wednesday, May 4, 2005:
>On May 4, 2005, at 1:16PM, James Bucanek wrote:
>
>> I have two processes (in some cases these are different threads, in
>> others different processes). A "client" process, which is the main
>> run loop of my Cocoa app. And a "worker" process, which the
>> "client" process initiates.
>>
>> In the client thread, I create the remote process/thread, create an
>> NSConnection, attach its receiver to the NSPort of my main run loop
>> (all of the methods for the vended object need to run in the main
>> loop), its sender to the NSConnection of the remote process, vend
>> my object, and sit back and wait for the remote process to call a
>> method in my vended object. (The vended object is, essentially, a
>> listener that tracks the state and collects the results of the
>> remote process.)
>
>I might be confused by the language but why should the server have
>any access to the client's NSConnection?
It doesn't/can't.
>For each DO connection
>between threads/processes there are two NSConnection objects, one on
>each end. Each end is responsible for its own NSConnection and
>shouldn't touch or even be aware of the NSConnection on the other
>end. So the server creates it's own NSConnection before vending and
>then gets rid of it after it stops vending. Each client creates its
>own NSConnection (from a pair of ports or +[NSConnection
>connectionWithRegisteredName:host:]) before starting a session with
>the server and gets rid of it after the session is complete. The
>server should not create an NSConnection for the client. I'm
>guessing your confusion is from the fact that one DO connection = 2
>NSConnections.
No, I don't think I'm confused. I've got all of that working just fine.
>Language/typo problems again. A client can't have a "vended listener
>object".
Sure it can. Either end of the NSConnection can set a rootObject, which the peer NSConnection can obtain a proxy for.
>If you vend an object you are a server. Maybe you just
>meant server there instead of client.
Language problems: What I've got, as I explained in the beginning, is a Cocoa app (thread #1) that spawns worker threads/processes (thread #2, #3, #4, ...). Now which thread is the client and which is the server? ;)
>Or are you doing two way
>communications between client and server?
Yes, as I explained I have a "command" object which is created in the worker thread/process and is vended back to the Cocoa app (the "client"). The Cocoa app (the "client") sends message to that command object to configure and control what the worker thread is going to do.
Likewise, the Cocoa app creates a "listener" object, which it vends to the worker thread/process. The worker thread/process can obtain a proxy for the listener object and send back results and progress information while it is working.
>In any case I think you do have to worry about the lifetime of the
>objects. Extracting copies of the data would work if you make sure
>to do deep copies. The bycopy keyword could also help. It's
>described in the "Proxies and Copies" section of http://
>developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
>RuntimeOverview/chapter_4_section_5.html
My main problem is the lifetime of the NSConnection object itself. Everything else pretty much takes care of itself, but I can't determine a definative time when the NSConnection object can be released.
If I let my application leak NSConnection objects, it works fine. ;)
If no one can come up with an answer to this, I might end up creating an NSConnection pool/factory and do some "lazy" garbage collection.
James
--
James Bucanek <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden