Lower the I/O priority of the installer when resonable.

chrome/installer/setup/run_all_unittests.cc

Index: chrome/installer/setup/run_all_unittests.cc
diff --git a/chrome/installer/setup/run_all_unittests.cc b/chrome/installer/setup/run_all_unittests.cc
index 1f55d012ee73ab1a5d6dbd4a33a713482f8c5489..a309b110884d6b9b074c427d76d882187803e28c 100644
--- a/chrome/installer/setup/run_all_unittests.cc
+++ b/chrome/installer/setup/run_all_unittests.cc
@@ -2,12 +2,19 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
+#include "base/command_line.h"
 #include "base/test/test_suite.h"
 #include "chrome/common/chrome_paths.h"
+#include "chrome/installer/setup/setup_util_unittest.h"
 
 int main(int argc, char** argv) {
   TestSuite test_suite(argc, argv);
 
+  // Handle the --adjust-process-priority switch, which is used to test the
+  // installer::AdjustProcessPriority() function in a subprocess.
+  if (CommandLine::ForCurrentProcess()->HasSwitch(kAdjustProcessPriority))
+    return DoProcessPriorityAdjustment();

[cpu_(ooo_6.6-7.5), 2013/05/31 19:09:49]

return  here ?

[grt (UTC plus 2), 2013/06/01 01:38:33]

Right. The idea is that when setup_unittests.exe is run with
--adjust-process-priority, it does nothing more than check the current priority
class and lower to background processing mode if relevant, and returns an exit
code indicating what it did (without running any unittests). This is triggered
by the new tests (SetupUtilTest.AdjustFromNormalPriority and
SetupUtilTest.AdjustFromBelowNormalPriority).

To re-state: running "setup_unittests --gtest_filter=SetupUtilTest.Adjust*" will
re-invoke setup_unittests with --adjust-process-priority (twice: once for each
test) to verify that installer::AdjustProcessPriority() can successfully drop to
bg mode where appropriate. Make sense?

+
   // Register Chrome Path provider so that we can get test data dir.
   chrome::RegisterPathProvider();