site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Sep 17, 2008, at 1:05 PM, Jerry Krinock wrote: On 2008 Sep, 17, at 8:47, Quinn wrote: <http://developer.apple.com/technotes/tn/tn2050.html> On 2008 Sep, 17, at 7:41, Philip Aker wrote: --Mike Zuhl _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... As far as doing this once you're running, I just updated TN2050 to described all of your various options. AFAIK launchd doesn't have any support for this sort of thing, so you'll have to run all the time. Indeed, NSWorkspaceDidTerminateApplicationNotification is what I currently use in my background app. Maybe kqueue with EVFILT_PROC NOTE_EXIT So, either way, if I insist on keeping this feature, I still need to have a continuously-running daemon of some kind. Hmmm. If any of your code (i.e., library functions) are running in these watched apps, there's another BSD way of watching for the app to quit. 1) Have your daemon set up a named pipe and accepts connections. You can do it with a thread per connection with a read(), or just a select (). 2) The first time your library code in the app gets run, it connects to the named pipe and does nothing else with the connections 3) When the app exits, the named pipe will be closed. The daemon will get an EOF on its end of the pipe--either by the thread's read() completing or the select() returning with activity on that connection I've done this under Linux where the only problem was hitting the limit of 1024 file descriptors on select(). (Yeah, I had a lot of processes to watch.) Of course, this scheme doesn't work for arbitrary processes that aren't using any of your code. This email sent to site_archiver@lists.apple.com