site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com In message <8F3679B6-2203-46A8-9D7C-A2CEA8D1BFB3@opendarwin.org>, Kevin Van Vec hten writes:

Historically it might have been safe to assume disk availability after "startup," but the whole point is that such assumptions are fragile at best, and therefore shouldn't be made. Disks (especially FireWire and USB) can come and go long after "startup," so it really isn't "the job of the startup system" to ensure that they're there. It's the job of the process.

I think it's the job of the sysadmin. Having every process constantly check for disk availability doesn't help all that much; it's load-creating, and it doesn't solve the problem. There comes a time when the UNIX philosophy should win; 10% of the coding does 90% of the job. Dealing with disk changes is probably a human task.

Correct. The StartupItem dependencies were not a panacea. In fact, a lot of third party applications had trouble with the dependency model as technologies moved from one startup item to the next (even before the shift to launchd). Maintaining dependency information in an abstract parallel universe is always prone to mistakes. The advantage of processes implicitly declaring dependencies (via blocking IPC etc.) or explicitly declaring them (via callbacks for system state changes) is inherently more robust.

It is, but inventing yet another new way of doing it doesn't help me much. :)

Actually you should have always tested for this in your code.

Should I? Since when? Since 1980? Since 1990?

configd is responsible for bringing up the network interfaces. Originally launched by a startup item, it was subsequently moved to a mach_init plist in Jaguar. The point is that there was never an explicit dependency here. If you want to replicate the historic behavior, then put a sleep(60) in your main() function and hope for the best, because this is essentially all that was ever happening anyway.

I'm not talking about "only on a Mac". I'm talking general UNIX. I don't have any interest in crippling my code to a single platform. The historical practice has been to figure out how your system provides ordering, and use that to launch code at the right time. On SysV, you link your init script to SXXdaemon, where XX is larger than the number for the network init script. In NetBSD/FreeBSD, you put "REQUIRE: network" in your rc.d script.

Interfaces can come and go dynamically even on Mac OS X Server, so I don't really buy the argument that detecting this fact isn't necessary on server systems.

When I say "server systems", I don't mean "systems running OS X server". I'm talking about general practices for people running a server. I've yet to see a real webserver want to use a dynamically up/down interface.

And the "new requirements" that lauchd "imposes" on your processes generally have been there all along, and it's just been a matter of luck that things worked without taking the time to address these issues.

No. Outside of the Mac, everyone's provided a nice luck-free way to ensure that items get launched at the right time. It might be as dumb as the very old "put it in /etc/rc after the things it depends on", but the ordering control has always been there. Launchd is expecting me to modify the code of my server application to solve an administrative task, and to do so in a completely Mac-specific way. No one else has done that. I can take a daemon written in 1990 and run it without modifying the code on any other system, by using their script or config file interface for specifying what its requirements are. On the Mac, I'm being told it's suddenly up to me to modify my application code. I'm not sure this is wrong; I think UNIX could benefit a lot from additional dependency handling in applications. However, it's a major change in philosophy, and the short-term effect is that, if I have to support more than one UNIX platform, the Mac is gonna be my absolute last choice, because it's the one that requires me to encode system-specific configuration knowledge into my code, rather than having that be in the part of the system that handles startup. I can no longer have a single unified source tree if I want to target the Mac. -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