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

chrome/installer/setup/run_all_unittests.cc

 // Copyright (c) 2009 The Chromium Authors. All rights reserved.
 // 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();
 
   return test_suite.Run();
 }