-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS AppNap put into idle YARP applications in background #1153
Comments
👍 @francesco-romano thanks for the details will look into it |
With @claudiofantacci we developed a simple macOS API wrapper to disable AppNap, see commit here: francesco-romano@4edc999 Of course this wrapper can be extended for other functions, but at the present state AppNap is the only "urgent" function to be implemented. In this commit we applied the new API to disable AppNap on
so it is 24 minutes that yarpdataplayer streams data without stopping, and AppNap is not on as shown in the ActivityMonitor We now have to find a "proper" and clean way to use this new API. Something like RAII (at least for the destruction part, I personally don't like to disable AppNap it in the constructor). Feedback is welcome |
ping (for everybody) to remember this issue |
I don't think SystemInfo is the right place for the toggle function... |
@drdanz where do you suggest this to go. Please consider that for mac users this is a very important feature! |
Not in a class that is named "something INFO" 😆 |
🤣 |
This was fixed in #1354 and it is available in YARP 2.3.72 |
Starting from macOS Mavericks (10.9) macOS supports a new feature (AppNap) with the aim of improving energy efficiency and battery life on notebooks.
Unfortunately, it uses some heuristics to decide which app may be put into "nap" (i.e. in a very low scheduling priority), see official documentation here.
As a consequence some yarp applications (e.g.
yarpdataplayer
) at some point stops sending data to their ports.As documented in Apple APIs, AppNap may be disabled using (unfortunately only) ObjectiveC calls in NSProcessInfo.
We have to test if this applies also to non UI applications, e.g. a simple main which in a run loop sends random data through an output port.
The text was updated successfully, but these errors were encountered: