[NSConnection release] anxiety
[NSConnection release] anxiety
- Subject: [NSConnection release] anxiety
- From: James Bucanek <email@hidden>
- Date: Wed, 4 May 2005 11:16:05 -0700
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.)
But then what?
The client's NSConnection isn't really "owned" by anything at this point. I can't autorelease it, or it will get destroyed as soon as I start the second process. (I tried that -- my app dies in a pile.)
The vended object (my listener) can't own it, nor can it release it in response to a remote message, because the release would happen *within* the call to the vended object -- and the connection would be destroyed before the response was returned. I also want to be able to run some worker processes with no feedback, in which case there is no listener object to begin with.
I suppose I could somehow defer the destruction of the client's NSConnection, but how long do I have to wait? Can I autorelease it in the same loop that calls a vended object's method? That seems very hazerdous, as I'm sure there are asyncronous communictions going on between the two NSConnections.
I see that there are notifications that are sent when an NSConnnectioon becomes invalid. But this state, apparently, only gets detected when you try to send a message *after* the connection has become invalid. Under normal conditions, there would be no messages sent following the destruction of the worker thread. Do I have to create a timer to periodically send a heartbeat message to the remote object, so I can get an NSConnectionDidDieNotification, so I can turn around and destroy the NSConnection object? Does that seem butt ugly to anyone else but me?
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.
--
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