• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Best way to ensure prevent multiplying helper tasks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 17:46:06 -0500

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
  • Follow-Ups:
    • Re: Best way to ensure prevent multiplying helper tasks
      • From: John Stiles <email@hidden>
References: 
 >Best way to ensure prevent multiplying helper tasks (From: Daniel Jalkut <email@hidden>)
 >Re: Best way to ensure prevent multiplying helper tasks (From: John Stiles <email@hidden>)

  • Prev by Date: NSNotification / Core Data roadblock
  • Next by Date: RE: Bundle Reloading
  • Previous by thread: Re: Best way to ensure prevent multiplying helper tasks
  • Next by thread: Re: Best way to ensure prevent multiplying helper tasks
  • Index(es):
    • Date
    • Thread