On Apr 25, 2006, at 12:51 PM, Dave Zarzycki wrote:
On Apr 25, 2006, at 10:35 AM, Kevin Brock wrote:
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.
I agree. For networking it's really a good idea. All my daemon is
doing is local IPC, so it's not really relevant in this case. If I
need to handle remote connections later it'll be a different (and
messier) story.
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.
I'm not sure I see how this works. In the header, launch_get_fd
takes no arguments, so I can't use it to register a callback. It
looks as though, if I call it at the right time, it will return a
file descriptor. It's not clear what context it should be called in,
or what fiel descriptor it will return... It *does* look as though I
have to poll it.
Kevin
_______________________________________________
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
