On Nov 30, 2009, at 5:06 AM, Uli Kusterer wrote:
> On 27.11.2009, at 18:40, Damien Sorresso wrote:
>> Put it in ~/Library/LaunchAgents. launchd has per-user variants. Or is there some reason this job needs to run in a privileged context?
> We don't need a privileged service, not at all. The problem is that this code may get used from several applications, and each of these applications needs a different instance. So we're registering a dynamic service name. It seems very messy to create files on disk for this, which need to be maintained, changed and reloaded when our app gets updated etc.
Ah I see. Maybe this facet of your use case got lost in all the other discussion. In any case, it sounds like bootstrap_register() is probably the most straightforward way for you to get there without having to have a parent spawn multiple helpers. If launchd ever implements multiple-instance job support, you can then just switch over to that.
> Also, bootsrap_check_in() doesn't seem to let you check out again when the helper is no longer needed or our app gets updated.
Correct. The idea is for launchd to hold onto the receive right after it's checked in. You can "check out" by unloading the job.
> bootstrap_register() seems like such a clean way to achieve this, so I'd really like to know what it does wrong that it is being deprecated, and why we'd need to resort to hacks like plists on disk here. It all seems kind of arbitrary, and neither Apple's docs nor several questions on this and previous threads about bootstrap_register() ever got an answer why it is deprecated.
It's not that is does anything "wrong". It's just that it's the old way of registering a MachService. The new way is through launchd. With bootstrap_register(), the client provides the bootstrap name server (launchd) with a send right, while it holds onto the receive right.
Since with launchd, we want to encourage a launch-on-demand pattern, we have the MachService described statically in a plist. launchd then creates a receive right that it holds onto, so that when that receive right gets a message, we can kick off the job. And when the job dies, launchd will get the receive right back so it can be kicked off on-demand in the future.
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