On Jul 23, 2008, at 1:09 PM, Karl Moskowski wrote:
I'm working on a Foundation tool to be used as a launchd daemon.
It's a Leopard-only GC app that uses FSEvents to watch for changed
files.
Can anyone offer any tips or guidance? Thanks.
I have a couple other tips, since you're writing a launch daemon using
Objective-C GC.
Some of this may not apply to your specific daemon, but it's stuff to
keep in mind in general when writing a Leopard-targeted Foundation
daemon that uses Objective-C GC. :)
(1) Do a launchd checkin.
I wrote a weblog post on this here:
launchd: Better than sliced bread!
http://chanson.livejournal.com/179229.html
Checking in with launchd will ensure that launchd actually passes you
the file descriptor you've asked for if you're running a service that
something is going to communicate with it. (It's also good launchd
hygiene.)
For example, your launchd property list can specify that your service
should be launched on-demand when a user connects to a secure UNIX-
domain socket. All processes subsequently launched by launchd will
get the path to this socket passed via an environment variable you
named, and your daemon when it checks in will actually be passed a
file descriptor for this socket. (You can even use that socket for
Distributed Objects via -[NSSocketPort
initWithProtocolFamily:socketType:protocol:socket:].)
(2) Start the threaded collector early on.
You can use objc_startCollectorThread() in <objc/objc-auto.h> to
ensure that the collector thread runs.
(3) Leverage NSRunLoop to run your "service loop."
Your example appears to be using it already, but for the archive's
sake, NSRunLoop is designed to be an abstract "event queue service
loop" for applications, regardless of whether they're UI applications
or not. If your daemon handles events (such as commands from clients)
you can treat them as a run loop source and let the framework do the
heavy lifting of multiplexing multiple input sources for you.
Once through your run loop is also a good place to hint to the
collector that it should collect if necessary. A non-GC app would
probably bracket the run of the run loop in an autorelease pool. A
decent technique for this is to get the underlying CFRunLoop from the
NSRunLoop (they're NOT toll-free bridged) and add an appropriate
observer to it that gets callbacks at appropriate points.
(4) Use NSOperation for your work queue.
Since you're using Leopard, you can use NSOperation for your units of
work. That will be easier than creating your own work queue system,
and using OS-provided constructs like NSOperation can help the system
better balance its overall load because it can take a holistic view
that an app-implemented work queue can't.
-- Chris
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
