Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: Peter Bierman <email@hidden>
- Date: Mon, 22 May 2006 10:26:12 -0700
At 3:05 AM -0500 5/22/06, Peter Seebach wrote:
Dave Zarzycki writes:
We only expect what our customers (including system administrators)
expect: Robust, easy to use and flexible software. I also have no
doubt that our customers want to see daemons be more resilient to the
real world, which will, in the end require the use of IPC.
Hmm.
This leaves us with two of launchd's goals in conflict; one is that apps
shouldn't have to contain extra code to handle the way they're launched,
the other is that they should robustly handle services which aren't up yet
but may be later.
No, the IPC mechanisms that launchd tunnels are generally ones that
block on connection attempts. So clients can be completely unaware of
launchd, or whether the service is always running or launched on
demand. And servers only need to declare to launchd what their
existing IPC mechanism is via a plist.
I guess, insofar as launchd is requiring me to rewrite code that's working
fine elsewhere, and add apple-specific startup magic, it's not a feature. It
may be that this inconvenience is worth it for the other benefits, but to
deny that it is an extra workload and an extra inconvenience is implausible.
If your "code" is an existing StartupItem that works, you don't need
to change it.
If your code is an existing IPC service, it's trivial to define that
service in a launchd.plist.
If your code is an IPC service that's currently wrapped in a
StartupItem, consider moving to launchd so that your clients don't
need to also use a StartupItem to declare their dependencies. That's
the major advantage of launchd: clients just use the services they
need, there's no additional declaration of dependency required.
-pmb
_______________________________________________
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