site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com seebs@plethora.net (Peter Seebach) writes: [speaking about disk arrival/departure detection] I'm not advocating polling models, there are callback models that suffice. 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. Like, say, launchd? I think you've swapped ends here... That's a perfectly good question that deserves a few answers. I'd be surprised if there is not a platform specific line of code in your program. As a service provider, you advertise your services passively. As a service consumer, you attempt to consume said services. The latter results in the invocation of the former. 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. They are? But by no means 99% of the services available on a Mac OS X system. = Mike _______________________________________________ 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... Wow. I can't actually say that I've seen such a collection of reactionary curmudgeonery in, well, a very long time. In message <5E024134-07E3-46B7-870D-268CB3D7ABB3@opendarwin.org>, Kevin Van Vec hten writes: Fair enough, but even MORE system-specific. Given that no other system you're going to touch with a ten-foot pole supports this in the first place, what do you expect? Freebies? As has been pointed out, on Mac OS and many other systems, disks come and go. If you are going to handle this at all, then you might as well accept that any volume other than the one you were loaded from may come and go at any time, in which case startup is just a special case. It's been a long time since the RA-81. You can actually pick a disk up and put it in your pocket, and this has changed the way people use them. You can't pretend that adding a new disk to the system must necessitate an electrician and a forklift anymore. [... continued ...] 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. 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. Mac OS X has the largest installed base of any Unix-like operating system. Period. It's the only Unix-like operating system that takes the desktop environment seriously. Period. It's the only Unix-like operating system that is attempting to adapt the way that the system thinks about people, rather than the other way around. Period. There may be some, but there's damn little. I write portable, standard, code. And thus you get portable, standard, lowest-common-denominator behaviour. As has already been pointed out, if you want to act like a piece of code from the 1970s, that facility is available. There are good reasons not to, some of which are consequent on the points I just made above. 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 don't see your point; this is exactly what Dave & co. are asserting with the launchd service dependency design. Where is there any sort of "dependency checking" in the consumer, or for that matter in the provider? Earlier, you wrote: In message <a06010200c097a2d8ab74@[192.168.0.222]>, Peter Bierman writes: The obvious counterexamples are sockets and file access. Launchd will happily spoof local sockets, so I don't see a counterexample there. As previously noted, if by "file access" you mean "the presence of a magic file" then it's down to the vector that presents the file. If you're expecting it to arrive via filesystem mount, then DiskArbitration does everything you want and a great deal more. If you are talking about a passive or implicit rendezvous (e.g. waiting for a PID file before attempting to contact a local service by some other means), then you are typically looking at an arrangement that tries to avoid a problem that the launchd model has made obsolete. You can remove code in this case... should make you happier again. 8) Which are, by strange coincidence, 99% of UNIX services. My opening point about reactionary behaviour and obstinacy bears some restatement. As Dave and Kevin and others have pointed out here, the launchd architecture is trying to solve some fundamental, undeniable problems with the way that services are invoked and managed. To hear someone say "disk arrival is a user event and should be managed by the user", or "services should start sequentially in a static order", or "I'm going to ignore this until there are two implementations and a standard chiseled into a block of solid diamond" is absurd; you should try saying it to yourself in front of a mirror and keep a straight face. .. Change is pain, and you really have just two choices; impede the process and contribute nothing, or align yourself with it and help these folks improve the world a little. This email sent to site_archiver@lists.apple.com