Re: Best way to ensure prevent multiplying helper tasks
Re: Best way to ensure prevent multiplying helper tasks
- Subject: Re: Best way to ensure prevent multiplying helper tasks
- From: Daniel Jalkut <email@hidden>
- Date: Fri, 16 Dec 2005 19:43:15 -0500
What I've decide to do is take advantage of the apparent reliability
of the service process connections' "localObjects" references. I've
added an NSTimer to my service process which will check all
connections for "localObjects" arrays of non-zero length. If it finds
any localObjects being retained by clients, it will not quit itself.
The host process now has the responsiblity of making sure that the
agent is running. The host tries to make a connection and obtain a
root object. If it fails, then the host tries to launch the agent
and does a limited polling wait until it can get a connection to the
newly launched process. It occurred to me that maybe a connection
could be made and then the agent times out before the host has
retained the root proxy. For this reason, I define "connection
success" as both connecting *and* getting a root proxy. If the root
proxy cannot be fetched, I relaunch the agent.
This seems to work pretty well, as the service process will never
quit itself while any other process retains objects for it. I've
confirmed that even force quitting a process causes its distant
objects to fall out of the other process's localObjects array.
The only part that makes me a little queasy is the polling wait for
the agent to launch, but that should be an exception condition so
long as I make the "auto quit" timer fairly long.
Daniel
On Dec 16, 2005, at 6:04 PM, Daniel Jalkut wrote:
Hmm, I'll have to think about that. In my particular case the
helper process is assisting a web browser plugin. So I don't
really want it to live on as long as the browser is running - just
as long as my plugin is using it, and maybe a few minutes longer.
I didn't know about that technote, though. I am sure that will
come in handy at some point.
Daniel
On Dec 16, 2005, at 5:52 PM, John Stiles wrote:
Your client process could quit itself if the server app dies by
observing process lifetimes:
http://developer.apple.com/technotes/tn/tn2050.html
This way you don't need timers or polling to determine if the
server app has died. (Although a timer that fires, say, once an
hour to check for the server app is hardly a big deal either.)
The sample code in this technote is horribly bloated, but the
techniques are applicable.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to 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