I've got a MacOS/X app which in general is not averse to app-napping, but sometimes it will spawn one or more child threads to do timing-sensitive networking tasks, which do need to avoid being app-napped.

The elegant thing to do would be to have each of these threads call [[NSProcess processInfo] beginActivityWithOptions [...]] when it starts, and also call [[NSProcess processInfo] endActivity [...]] just before it exits, which would (hopefully) have the effect of avoiding app-nap on my process (or at least on those particular threads) only when one or more of these network-threads is running.

My question is, is this a legal/acceptable calling pattern, or is NSProcessInfo more of a per-process-only kind of API that doesn't implement the thread-safe reference-counting logic that would be necessary to reliably yield the expected behavior if I call it from multiple threads? (if it's the latter, I can implement that logic myself, but I'd rather not reinvent the wheel here)

CodePudding user response：

This API is considered like process-wide, to report that your entire Application is doing the specific kind of job, which should be or should not be affected by power saving heuristics (which are, again, per-process, not per-thread).

The best way to use it would be to begin one activity before all your background thread started, and finish it after all your important background threads finished.

You can do it with DispatchGroup or any other instrument you wish.

That is not the only way though.

beginActivityWithOptions would return the _NSActivityAssertion, which is not generally aware of threads. You could bring your own thread sync mechanism to this party.

Calling this API several times would create several _NSActivityAssertion objects, which is definetely redundant but should work, if you will properly end each of them.