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: John Stiles <email@hidden>
- Date: Fri, 16 Dec 2005 14:52:44 -0800
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.
On Dec 16, 2005, at 2:46 PM, Daniel Jalkut wrote:
Thanks, John. It's nice to see one real-life example of a solution
to a similar problem.
I am already using distributed objects to communicate between the
server and client processes, so I could just "launch if no
connection exists." But that doesn't solve the urge I have to make
sure that the server gets terminated by the client when it's done
with it.
The more I think about it the more I think the best solution is
simply to "launch if no connection" and then have the server
process time itself out after some period of inactivity.
The question this raises is how best to detect inactivity in the
server. I have a very limited number of entry points on the root
object, but once a client has the root object they may be
manipulating objects referenced by that root without going through
my top-level "fetcher" method.
It looks to me like a smart way to handle "idleness" in terms of a
server process that only responds to NSConnection-based requests,
might be to use the "connection:handleRequest:" delegate method to
provoke continual setting of a self-termination NSTimer. Thoughts?
Daniel
On Dec 16, 2005, at 2:15 PM, John Stiles wrote:
This sounds a bit like a problem I had to solve a year or two ago.
I had an app that needed to see if another copy of itself was
already running (and switch to it, if so). However, the "app" was
also defined by its data set--you could have two copies running
with different data, and to the end user, it felt like two
separate unrelated apps, and they'd want to run them both at the
same time.
I ended up using Distributed Objects and it worked great. This
technique is probably adaptable to your situation.
bool SwitchToAlreadyRunningInstance()
{
NSString *appName =
[NSString
stringWithUTF8String:s_uniqueStringIdentifyingThisApp];
NSDistantObject *otherApp =
[NSConnection rootProxyForConnectionWithRegisteredName:appName
host:NULL];
if( otherApp != NULL )
{
[(id)otherApp wakeUp]; // cast to id to get around warning
"receiver cannot handle this message"
return true;
}
NSConnection *theConnection = [NSConnection defaultConnection];
[theConnection setRootObject:s_app]; // <-- that's my main class
[theConnection registerName:appName];
return false;
}
On Dec 16, 2005, at 11:11 AM, Daniel Jalkut wrote:
I'm using NSTask to spawn a "service agent," which gets
terminated when my application quits. On rare occasion, the
service agent may not terminate. Particular during testing, when
my application crashes, the code that would terminate the helper
agent never gets reached.
I want to avoid a worst-case scenario where the user's computer
gets littered with a bunch of processes. Although it seems
unlikely to happen unless my app starts crashing like crazy, I'd
still feel more comfortable if I could guarantee that there is
always at most one helper task.
I can avoid launching a *new* task by simply attempting to
connect to a named service through NSConnection. If I get the
connection, then my task must already be running. Once I have
this connection, though, what's the best way of making sure that
it goes away when I'm done? Can I get an NSTask for an arbitrary
NSConnection?
Perhaps the simplest solution would simply be to always launch if
the connection fails, and then have the helper task quit itself
if idle for a certain length of time?
I'd appreciate any wisdom if you have it to share. Thanks!
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.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