Avoid profiler initialization in exe context

The profiler is "really" only useful in the
DLL, and there was one lingering Thread::SetName
call that (accidentally) initialized the
profiler in the exe context.  This change
avoids starting the profiler for that thread
which is only part of the exe, and is never used
for spawning or running tasks (profiled items).

r=rvargas
bug=103321
Review URL: https://chromiumcodereview.appspot.com/9432011

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123047 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 10 insertions, 2 deletions

diff --git a/base/threading/platform_thread_win.cc b/base/threading/platform_thread_win.cc
index 5cd96c1..1bb50c5 100644
--- a/base/threading/platform_thread_win.cc
+++ b/base/threading/platform_thread_win.cc
@@ -1,4 +1,4 @@
-// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Copyright (c) 2012 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.
 
@@ -121,7 +121,15 @@ void PlatformThread::Sleep(TimeDelta duration) {
 // static
 void PlatformThread::SetName(const char* name) {
   current_thread_name.Set(const_cast<char*>(name));
-  tracked_objects::ThreadData::InitializeThreadContext(name);
+
+  // On Windows only, we don't need to tell the profiler about the "BrokerEvent"
+  // thread, as it exists only in the chrome.exe image, and never spawns or runs
+  // tasks (items which could be profiled).  This test avoids the notification,
+  // which would also (as a side effect) initialize the profiler in this unused
+  // context, including setting up thread local storage, etc.  The performance
+  // impact is not terrible, but there is no reason to do initialize it.
+  if (0 != strcmp(name, "BrokerEvent"))
+    tracked_objects::ThreadData::InitializeThreadContext(name);
 
   // The debugger needs to be around to catch the name in the exception.  If
   // there isn't a debugger, we are just needlessly throwing an exception.