site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com In message <5E024134-07E3-46B7-870D-268CB3D7ABB3@opendarwin.org>, Kevin Van Vec hten writes:

I'm not advocating polling models, there are callback models that suffice.

Fair enough, but even MORE system-specific.

In the short term I agree with you. You have some more work to do, but in the long term, this approach is sustainable and hopefully will not require further churn.

It may or may not. I just don't find myself convinced that every daemon in the world should acquire all this extra sanity-checking. I like to isolate repetitive tasks; I would rather see ONE program to dependency checking than DOZENS.

...

Since when? Since 1980? Since 1990?

Since Mac OS X 10.0. I can't/won't speak for earlier systems.

Imagine that I'm a UNIX guy with a half-dozen machines already running. Why should I care about OS X? It's imposing a totally new model on my code that contradicts how my code has worked fine on every other system for twenty years.

I'd be surprised if there is not a platform specific line of code in your program.

There may be some, but there's damn little. I write portable, standard, code.

You can wrap your launchd support in #ifdef __LAUNCHD__ or something equivalent. It's overstating the problem to say that you can't have a unified code base. Adding Launchd support is a relatively small amount of code, I know from experience. I think your sysadmins (customers) will ultimately be pleasantly surprised by this investment. Your server can be automatically kept alive. This and other servers can be uniformly launched, stopped, and queried via launchctl or programmatically.

Hmm. Tell you what: When there's a published standard that is not Apple-specific, and a second independent implementation I can compare with, I'll think about it. Right now, I have Apple totally overhauling the way daemons are started. I have no reason to believe that this one will survive.

It's clear you're dissatisfied with having to change from what you're used to, and I appreciate that. I don't think any further amount of discussion is going to change that. However, I think you'd be pleasantly surprised if you gave the launchd model a chance.

I think it has some potential. But ultimately, the more I think about it, the more I think it's just plain wrong. Dependency checking is not something that should be duplicated in every program.

I think your concerns are completely legitimate, but we're faced with a difference in opinion as to how they're most effectively addressed (i.e. are they a startup problem or a process problem?) I suspect the best solution is for more documentation and sample code to be written about launchd, to illustrate how to achieve these goals within your process.

Yes. Well, as a recent example, I have an existing fire-and-forget program. I don't want to modify it. How should I do a launchd.plist file to start it? The obvious idea is to use RunAtLoad. If you do this, launchd hangs forever. Why? Because despite every last piece of documentation saying that you must NEVER fork and detach, and you MUST NOT close file descriptors, if you don't fork-and-detach and close file descriptors in a RunAtLoad process, launchd waits for it to terminate before doing anything else. I could, I suppose, rewrite my program to add launchd checking and so on to what is essentially a ten line shell script with a while loop. I'm not sure how I'd go about doing this, because my kornshell documentation makes no mention of a fully functional IPC system. My objection here is not to the basic idea of the launchd model for many things; I think it is hands down the best way I've seen to handle inetd/cron jobs or their equivalents. I just think it's doing an awful job of replacing rc.d/startupitems. It's good for on-demand launches; it's not doing nearly as good a job of startup. Philosophically, it's right about inetd/cron. It eliminates the need for daemons to do their own setup work and have everyone duplicate the various attempts to drop privileges as soon as possible but not to soon, and so on. It REDUCES code duplication. Philosophically, it's wrong about startup. It CREATES the need for daemons to do their own dependency checking, and requires everyone to duplicate all the code to handle this, add new mechanisms, and so on. It INCREASES code duplication. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com