On Oct 14, 2005, at 3:32 PM, Merle McClelland wrote:
Thanks for the detailed response! That answers my questions. I
wasn't aware of the AppleEvent pinging since my daemon isn't
explicitly using AppleEvents.
Most of the work performed by the daemon is within separate threads
invoked by the main process. Most of the time the main process is
in the CFRunLoop, waiting for an event. However, periodically, the
main process does do some work within the context of the timer and
the IOManager callbacks. Based on your explanation, I suspect that
it is this processing (which sometimes can cause the main process
to wait for the other threads to do their stuff before exiting the
callback) that is causing an occasional lack of response to the
AppleEvent ping.
If you register for them, then you are subject to pinging. Vanilla
UNIX code won't show status like this unless it goes out of its way
to either replicate the interfaces or includes a CFRunLoop.
If you could do without that, you'd be safe from pinging and looking
like you're hung.
I'll have to evaluate moving these periodic functions to a
background thread so that the main process doesn't get tied up
performing the work. Sounds like I'll have to implement the
interlock as you suggest since in this design the main process
won't be doing much of anything. Given that my process is a daemon
without a GUI (and is designed to run even when users aren't logged
in), I can't directly display error dialogs. The cross-platform
code using ZThread has a monitoring capability to handle hung
worker threads. However, it appears I need to have one additional
thread layer between the main process and the lower-level threads
to off-load the main process from potentially long-term work that
may occur periodically.
Is there a good example of writing a MacOS daemon that properly
handles these scenarios? The "MyFirstDaemon" sample code doesn't
cover these issues.
I'm not sure. My understanding here comes from your question
prodding me to actually go investigate something that I'd had
questions about previously, but never bothered to go research an
answer. I could find a little documentation in a couple of google-
able forums that discussed the "Not Responding" in Activity Monitor,
but didn't answer the "recent hangs" question, so I went and read the
source code for Activity Monitor.
I don't know of any sample source code that does what I described; I
based the answer on general software engineering principles.
It looks like the ping interval for the busy cursor is 2 seconds, and
the ping interval for the Activity monitor is 1 second, so at a
minimum your usleep()'d be 1/2 of 1 second, minus 1 - standard
programmatic mechanism for a generic resource "lease" operation.
You'd want enough leeway that you could do work, and handle ordinary
events in a timely way, so 499999 microseconds argument to usleep()
in the monitor might be too large (if the work it did before the next
event took more than 1uS, you'd risk looking "hung").
I can't find the MyFirstDaemon sample code; it looks like it was
removed because of the launchd changed (daemons in the launchd world
are not supposed to fork or put themselves in the background).
...which has no CFRunLoop. If you don't depend on having one, that'd
be easiest; otherwise, you can add a thread.
Thanks again,
- Merle
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden
