osx: disable app-nap programatically #5804

1. 
   theuni commented at 10:59 pm on February 18, 2015: member

   Currently for OSX we’re disabling app-nap globally via the app’s plist. If enabled, app-nap slows down performance badly for long-running activities. See #5041 for more background.

   Disabling via the plist has a few draw-backs:

   • The plist setting only has an effect when running from an .app bundle. In practice, that means only when running from a packaged release
   • We don’t distribute bitcoind in the bundle and likely never will. So app-nap is always enabled for bitcoind.
   • App-nap can actually be a useful feature. It would be helpful to only disable it at certain times (initial sync for example)

   These changes add runtime functionality so that we can turn it on/off at-will. For now, it’s enabled for the life-time of the programs, but that can be changed once we decide how to regulate it.

   The CIdleInhibitor class is very ugly, but I assume that at some point we’ll add similar features for other operating systems. I think this is nicer than osx ifdefs all over the place. I avoided inheritance and virtuals since we’re interfacing with objc.

   Needs testing on < 10.9 systems.

2. theuni force-pushed on Feb 18, 2015
3. osx: enable app-nap to be controlled at runtime

   For now, disable for the life of bitcoind and bitcon-qt to achieve the same
   behavior as before. More fine-grained behavior can come after more testing.

   d76353e790
4. osx: remove hard-coded app-nap setting 0fff6b7e9b
5. in src/appnap.h: in 0fff6b7e9b

   0@@ -0,0 +1,20 @@
   1+// Copyright (c) 2009-2010 Satoshi Nakamoto
   2+// Copyright (c) 2009-2014 The Bitcoin Core developers
   3+// Distributed under the MIT software license, see the accompanying
   4+// file COPYING or http://www.opensource.org/licenses/mit-license.php.
   5+
   6+#ifndef BITCOIN_APPNAPINHIBITOR_H
   

   ---

   ---

   

   laanwj commented at 9:44 am on February 19, 2015:

   Please don’t add these kind of one-use utilities in the top-level src directory. As I’ve suggested before, a an src/support or such directory would make sense.
6. laanwj added the label Priority Low on Feb 19, 2015
7. laanwj added the label Mac on Feb 19, 2015
8. 
   laanwj commented at 9:48 am on February 19, 2015: member

   Sorry to say but I’m not entirely convinced of adding mac-specific code to the core code. In the GUI this is more acceptable (and even there we like to avoid it if possible), but I don’t know here. The plist-based solution works, so this reeks a bit of “Don’t fix it, it’s not broken” to me.
9. in src/appnap.mm: in 0fff6b7e9b

   0@@ -0,0 +1,28 @@
   1+#include "appnap.h"
   2+
   3+#include <AvailabilityMacros.h>
   4+#include <Foundation/NSProcessInfo.h>
   5+#include <Foundation/Foundation.h>
   6+
   7+class CAppNapInhibitorInt
   

   ---

   ---

   

   laanwj commented at 9:49 am on February 19, 2015:

   Objective C in the core? :(
10. 
    theuni commented at 4:47 pm on February 19, 2015: member

    Ok. I was under the impression that some of our non-qt deps required objc and frameworks already, but looking at the link-line, that’s not the case. So I agree with the no-objc argument.

    Closing as not worth it.

11. theuni closed this on Feb 19, 2015

    ---

12. 
    jonasschnelli commented at 10:43 am on March 5, 2015: contributor

    Hmm… i kinda liked this. Obj-c in core should be avoided, right. Maybe we find a more modular approach? env_mac.mm? I assume other OS will also come with/have similar low-energy technologies. Related to #5314 and #5344
13. DrahtBot locked this on Sep 8, 2021

Contributors
theuni laanwj jonasschnelli

Labels
macOS