On and off I've been trying to figure out how to do hang detection in-application (at least from the user's point of view). Qualitatively what I'd like to do is have a process which runs sample(1) on the application after it's been unresponsive for more than a second or so. Basically, an in-app replacement for Spin Control. The problem I've been stuck on is: how do I tell? There used to be Core Graphics SPI (CGSRegisterNotifyProc with a value of kCGSEventNotificationAppIsUnresponsive) for doing this, but it doesn't work anymore (either due to sandboxing or system-wide security changes, I can't tell which but it doesn't matter). One thought I had was to have an XPC service which would expect to receive a checkin once per second from the host (via a timer set up by the host). If it didn't, it would start sample(1). This seems pretty heavyweight to me, since it means that once per second, I'm going to be consuming cycles to check in with the service. But I haven't been able to come up with a scheme that doesn't include some kind of check-in by the target process. Are there any APIs or strategies that I could use to accomplish this? Or is there some entitlement which would allow the application to request "application became unresponsive"/"application became responsive" notifications from the window server?

Given a pid_t, is there an efficient way to determine what child processes it has spawned? I found proc_listchildpids() in <libproc.h>, but there is no documentation for it. (I've been able to figure out that the argument is an array of pid_t, but as far as I can tell there's no way to know up front how much space I should allocate.) Somewhat related: given a pid_t, is there a way to get notified when that process spawns a child process, as well as when any child process exits? (I don't know in advance what processes will be created or when they'll terminate, so I can't keep track separately.) I know that DISPATCH_SOURCE_TYPE_PROC exists, and while that's in the general area, it looks like I'd have to do a fair amount of secondary bookkeeping to keep track. Thanks for any advice. :-)

I filed FB7836460 about a warning from ranlib when compiling static libraries from the command line. Here's a representative warning (I've seen it for multiple libraries): /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: lib[redacted].a([redacted].c.o) offset in archive not a multiple of 8 (must be since member is an 64-bit object file) (The installed Xcode version is 12A8158a, if that matters. “ranlib" doesn’t have an option for reporting its version.) My application seems to link OK against those libraries despite the warning, but is there any cause for concern here? Is this something I can resolve with an appropriate command-line flag to the compiler?