Very early load and usage of higher level APIs
Very early load and usage of higher level APIs
- Subject: Very early load and usage of higher level APIs
- From: Ryan McGann <email@hidden>
- Date: Thu, 8 Jun 2006 22:56:26 -0700
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.
- 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? For
now, I've hacked around these issues by doing a very kluddy for loop:
for ( int i = 0; i < 5; i++ )
{
// Call Alia Manager needlessly
// Call cdsaCspAttach uneedlessly
}
But this seems just as error prone, since as machines get faster we
might need to change the loop to 10 iterations, etc. Any suggestions?
Thanks,
Ryan
email@hidden
_______________________________________________
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