Re: [NSConnection release] anxiety
Re: [NSConnection release] anxiety
- Subject: Re: [NSConnection release] anxiety
- From: Frank Midgley <email@hidden>
- Date: Wed, 4 May 2005 17:55:01 -0500
On May 4, 2005, at 1:16PM, James Bucanek wrote:
I've got an ownership problem with NSConnections and distributed
objects.
In a nutshell, I don't know when I can release the NSConnection(s).
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? 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.
I have a similar anxiety about the worker process. The remote
process is a little simplier, in that it creates a new thread and
run loop to drive the NSConnection and the remote worker object.
The worker objects start <n> number of threads that run until the
procedure is complete. The data is "returned" via a sequence of
calls back to the client's vended listener object. But, if I
understand Distributed Objects correctly, the objects that the
client process ends up with are actually proxies of the actual data
objects in the worker. If my worker thread immediately terminates,
the NSThread, its NSConnection, and the NSPorts used to connect
them are now all gone. The client process now can't send any
messages to the returned data objects, because there's no process
at the other end to respond.
I could solve the last problem by making sure the client callbacks
extract copies of all of the returned data and make sure everything
is local before returning.
Language/typo problems again. A client can't have a "vended listener
object". If you vend an object you are a server. Maybe you just
meant server there instead of client. Or are you doing two way
communications between client and server?
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
Hope this helps...
-Frank
------------------------------------
Frank M. Midgley
email@hidden
http://homepage.mac.com/knarf/
_______________________________________________
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