Re: Very early load and usage of higher level APIs
Re: Very early load and usage of higher level APIs
- Subject: Re: Very early load and usage of higher level APIs
- From: Kevin Van Vechten <email@hidden>
- Date: Fri, 9 Jun 2006 01:28:05 -0700
I'm responding off the top of my head, so I could be wrong, but I
believe your analysis is correct and the Carbon File Manager does
rely on coreservicesd to some extent, and the Security.framework
relies on securityd as well.
In the "launchd model" you should not have to specify a dependency.
(The fact that a daemon is consulted is really and implementation
detail of the API you're calling.) These APIs should be making
blocking calls to the daemons in question--and launchd should launch
the daemons when the calls are made.
The fact that this isn't happening is a bug in the system, not in
your code.
I can imagine a few possible explanations (but this is pure
speculation):
* launchtl might be somewhat non-deterministic in how plists are
loaded. If at times your plist is loaded before the coreservicesd or
securityd plist, then the lookups for those services will fail, which
causes the API to return an error rather than block.
* coreservicesd or securityd might not be properly servicing requests
before they're fully initialized. They should not service requests
until they've initialized themselves, but perhaps they're dequeuing a
message they can't handle yet and returning an error.
It would help tremendously if you could file a bug <http://
developer.apple.com/bugreporter/>. Distilling it into a small test
case, or at least describing the specific API calls you're making,
will help us diagnose the problem.
- Kevin
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.
- 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