Re: Launchd and domain sockets, accept() problem (was Re: launchd APIs)
Re: Launchd and domain sockets, accept() problem (was Re: launchd APIs)
- Subject: Re: Launchd and domain sockets, accept() problem (was Re: launchd APIs)
- From: Dave Zarzycki <email@hidden>
- Date: Tue, 25 Apr 2006 12:51:46 -0700
On Apr 25, 2006, at 10:35 AM, Kevin Brock wrote:
I did figure out what the accept problem was, and it wasn't launchd
related. At this point everything seems to be working well.
On Apr 25, 2006, at 8:17 AM, Dave Zarzycki wrote:
Also please please please don't ever assume that only one socket is
in the array. I really want system administrators to feel that they
can add additional socket declarations to jobs and "everything
should just work (TM)." :-)
I'm not sure that I agree with this in every case. If a daemon is
listening on a particular socket, and the framework used to write an
app that uses this daemon also uses a particular socket, then the
admin really shouldn't be messing with it. I'd guess you're talking
about the case where they want the daemon to be listening to an
additional socket... Not a lot of justifiable reasons for doing
that, but I'll look at modifying the code to handle it.
This really is more applicable to networking. Imagine for a second a
socket definition that says listen on any interface on IPv4 or IPv6.
That will generate two descriptors. The system administrator might
then change the configuration file to listen on IPv4 on interface A
and B and IPv6 on interface B and C. Now we have four sockets, all the
while, the daemon is blissfully unaware.
Changing parameters for the heck of it is never a good idea.
For local IPC, I'd agree, but like I pointed out, it can be really
useful for networking.
The one question left is related to launchd messages. Sampled uses
exactly one. LAUNCH_KEY_CHECKIN. It doesn't show any examples of,
e.g., LAUNCH_KEY_STARTJOB, LAUNCH_KEY_STOPJOB, etc. Are any of the
other messages in launch.h of potential interest to a daemon, or are
they for internal use only?
Daemons should only need to check-in.
Unless you're interested in implementing your own launchctl, the other
messages aren't that interesting.
The comment in the header says that calling launch_msg() with no
message is a way to receive asynchronous messages. Polling this
seems clunky... Is there a way to register a callback for
asynchronous messages?
Yes, that's what launch_get_fd() is for.
Are there any asynchronous messages I should be looking for?
Nope, nothing uses that at the moment.
davez
_______________________________________________
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