• 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: Very early load and usage of higher level APIs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Very early load and usage of higher level APIs


  • Subject: Re: Very early load and usage of higher level APIs
  • From: Shaun Wexler <email@hidden>
  • Date: Fri, 9 Jun 2006 05:02:39 -0700

On Jun 8, 2006, at 10:56 PM, Ryan McGann wrote:

Now that the launchd discussion has died down, I guess it's time to kick up the ashes with an honest question. We are using launchd in Tiger to startup our daemon. It is currently not load-on-demand, so it gets launched very early. It's usually process ID 18-25.

We seem to be experiencing some problems in Tiger related to how early we get started. In particular, the following APIs seem to rely on daemons to perform their dirty work, but those daemons are not ready when we use them:
- The Carbon Alias Manager which is used to determine the location of some files saved in the preferences accessed by our daemon. Sometimes the Alias Manager fails to resolve the aliases, even though they point to files that have not changed. We are using FSResolveAliasNoUI to resolve the alias in our daemon.

Carbon is not daemon-safe, so you're SOL there. Tech Note 2083: <http://developer.apple.com/technotes/tn2005/tn2083.html>

- The cdsa wrapper libCdsa, which fails sometimes in cdsaCspAttach
Both of these issues are reliably unreliable, in that they happen every 1 out of 5 reboots or so. It took quite a bit of time to narrow things down, but by adding a LOT of syslog statements, we found that these two APIs randomly fail. Looking at the syslog and process list in ps, I see that coreservicesd is launched very soon after our daemon, so I am guessing that the Carbon File Manager uses coreservicesd. I am *guessing* that the Security framework uses securityd.


Since launchd has no dependancy list, how can I tell launchd that we need these daemons launched *and ready* when our daemon loads?

Of course this won't work for services that are on-demand/inactive, but how about something like this (untested, written in Mail):


#include <mach/mach_time.h>
#include <servers/bootstrap.h>

char *servicename[] = {
    "com.apple.CoreServices.coreservicesd",
    "com.apple.windowserver.active"
};

bootstrap_status_t serviceactive;
mach_timebase_info_data_t info;
(void)mach_timebase_info(&info);
uint64_t poll_interval = 1000000000ULL * info.denom / info.numer; // 1 second
uint32_t i = 0;


do {
while (bootstrap_status(bootstrap_port, servicename[i], &serviceactive) == BOOTSTRAP_UNKNOWN_SERVICE && ! serviceactive) {
mach_wait_until(poll_interval + mach_absolute_time());
}
} while (++i < sizeof(servicename) / sizeof(servicename[0]));


HTH~
--
Shaun Wexler
MacFOH
http://www.macfoh.com

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Very early load and usage of higher level APIs
      • From: Dave Zarzycki <email@hidden>
    • Re: Very early load and usage of higher level APIs
      • From: Eric Albert <email@hidden>
References: 
 >Very early load and usage of higher level APIs (From: Ryan McGann <email@hidden>)

  • Prev by Date: Re: the Virtual Memory
  • Next by Date: Re: Very early load and usage of higher level APIs
  • Previous by thread: Re: Very early load and usage of higher level APIs
  • Next by thread: Re: Very early load and usage of higher level APIs
  • Index(es):
    • Date
    • Thread