Wow. I can't actually say that I've seen such a collection of
reactionary curmudgeonery in, well, a very long time.
email@hidden (Peter Seebach) writes:
[speaking about disk arrival/departure detection]
In message <email@hidden>,
Kevin Van Vec
hten writes:
I'm not advocating polling models, there are callback models that
suffice.
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 ...]
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.
Like, say, launchd? I think you've swapped ends here...
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.
That's a perfectly good question that deserves a few answers.
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.
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.
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.
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.
Where is there any sort of "dependency checking" in the consumer, or
for that matter in the provider?
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.
The obvious counterexamples are sockets and file access.
They are?
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.
But by no means 99% of the services available on a Mac OS X system.
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
