【发布时间】：2020-10-17 15:12:42
【问题描述】：
我在 Mac OS X 上有一个 C++ 应用程序。该应用程序在主线程上使用 glfw 库运行事件处理，并在后台 C++std::thread 上读取输入和执行命令。
我正在观察一个令人沮丧的现象，目前我无法解释。
如果我在后台线程上调用一个长时间运行的函数，最初该线程正在使用 100% 的内核。但是，在它使用了几秒钟的 CPU 之后（10 似乎是神奇的阈值），它会被限制到 25%。
如果我在启动 glfw 事件处理循环之前在后台线程上启动计算运行（事件处理基本上卡在等待事件，因为我什至没有打开窗口），那么它可以使用 100%只要它愿意。
我最大的问题是我不知道是什么原因造成的，也不知道如何解决。我已经测试了检索 pthread sched_param 并将 sched_priority 从默认的 31 更改为 20 到 60 之间的各种值，但没有帮助。
我已经确定了该现象发生的另一种条件： 后台线程必须从终端读取。当我运行以下后台线程并输入一行以进行计算时，就会发生这种情况：
std::thread cmd([argc, argv, &scriptingRunner] {
for (std::string line; std::getline(std::cin, line); ) {
longComputation();
}
【问题讨论】：
-
大胆猜测：也许 App Nap 正在限制您的应用程序以节省能源。要检查，打开Activity Monitor程序并右键单击进程表的标题以弹出上下文菜单，然后单击上下文菜单中的“App Nap”以启用App Nap列；然后在表中查看你的进程，看看它在 App Nap 列中的值是否在故障发生时切换为“是”。
-
我在活动监视器中看不到该菜单。请参阅我对发生这种现象的其他条件的编辑。
-
我发现了。谢谢。 “午睡”是永久的。但这可能是来自 glfw 的正在等待事件的线程吗？现在我正在观察更奇怪的行为。自从计算机进入“暗模式”以来，只有 25% 的同一线程大部分时间都回到了 100% ......不确定它是否相关。重新启动后，我再次看到 25% 的使用率。在发现 glfw 事件进程中的主线程和从终端完成输入的受限制线程的组合之后，我将创建一个尽可能简单的代码来执行此操作。如果它显示出这种行为，我会发布它
-
@JeremyFriesner 你是对的。您拥有的链接给了我一个 404 错误。你还有一个吗？如果你这样做，把它放在一个答案中，我会选择它作为正确答案。一些谷歌搜索一些代码会产生其他你讨论相关主题的stackoverflow页面。我还发现了一些 C++/C 代码，但它不会在较新的 MacOS 中编译，因为
objc_msgSend没有用它的参数声明。我使用defaults write NSGlobalDomain NSAppSleepDisabled -bool YES完全禁用了我电脑上的应用程序小睡，并且确实这种现象不会再次发生。
标签： multithreading macos pthreads throttling