summaryrefslogtreecommitdiffstats
path: root/chrome/browser/in_process_webkit/webkit_thread.cc
diff options
context:
space:
mode:
authorchase@chromium.org <chase@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-25 22:40:12 +0000
committerchase@chromium.org <chase@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-25 22:40:12 +0000
commitc37f3e0fce65fb28618384916deb712693bfce73 (patch)
tree3f915db21580364fb5013e3b3c2134b7800745a4 /chrome/browser/in_process_webkit/webkit_thread.cc
parentd6d1774e7fe541c36489a5dbbb19ce6acfa097ad (diff)
downloadchromium_src-c37f3e0fce65fb28618384916deb712693bfce73.zip
chromium_src-c37f3e0fce65fb28618384916deb712693bfce73.tar.gz
chromium_src-c37f3e0fce65fb28618384916deb712693bfce73.tar.bz2
RESUBMIT of http://codereview.chromium.org/404025/show
Start the WebKit thread when we initialize the resource dispatcher host. NOTE: It's very possible this will have a startup performance impact. I'm going to watch the bots after committing. TODO: Clean up shutdown logic that exists simply because we don't know whether or not we'll ever start the WebKit thread. Originally landed in r33063, reverted in r33101 due to coincidence with Modules Linux startup test failures. TBR=jorlow, darin TEST=The WebKit thread gets spun up early in the initialization process. BUG=24144,28364 Review URL: http://codereview.chromium.org/441025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33144 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/in_process_webkit/webkit_thread.cc')
-rw-r--r--chrome/browser/in_process_webkit/webkit_thread.cc31
1 files changed, 13 insertions, 18 deletions
diff --git a/chrome/browser/in_process_webkit/webkit_thread.cc b/chrome/browser/in_process_webkit/webkit_thread.cc
index 6311140..c3ad81f 100644
--- a/chrome/browser/in_process_webkit/webkit_thread.cc
+++ b/chrome/browser/in_process_webkit/webkit_thread.cc
@@ -9,9 +9,7 @@
#include "chrome/common/chrome_switches.h"
#include "third_party/WebKit/WebKit/chromium/public/WebKit.h"
-// This happens on the UI thread before the IO thread has been shut down.
WebKitThread::WebKitThread() {
- // The thread is started lazily by InitializeThread() on the IO thread.
}
// This happens on the UI thread after the IO thread has been shut down.
@@ -23,11 +21,19 @@ WebKitThread::~WebKitThread() {
DCHECK(!ChromeThread::CurrentlyOn(ChromeThread::WEBKIT));
}
-void WebKitThread::EnsureInitialized() {
- DCHECK(ChromeThread::CurrentlyOn(ChromeThread::IO));
- if (webkit_thread_.get())
+void WebKitThread::Initialize() {
+ DCHECK(ChromeThread::CurrentlyOn(ChromeThread::UI));
+ DCHECK(!webkit_thread_.get());
+
+ if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kSingleProcess)) {
+ // TODO(jorlow): This thread should be used (and started) in single process
+ // mode rather than following different code paths.
return;
- InitializeThread();
+ }
+
+ webkit_thread_.reset(new InternalWebKitThread);
+ bool started = webkit_thread_->Start();
+ DCHECK(started);
}
WebKitThread::InternalWebKitThread::InternalWebKitThread()
@@ -43,21 +49,10 @@ void WebKitThread::InternalWebKitThread::Init() {
webkit_client_.reset(new BrowserWebKitClientImpl);
WebKit::initialize(webkit_client_.get());
// If possible, post initialization tasks to this thread (rather than doing
- // them now) so we don't block the IO thread any longer than we have to.
+ // them now) so we don't block the UI thread any longer than we have to.
}
void WebKitThread::InternalWebKitThread::CleanUp() {
DCHECK(webkit_client_.get());
WebKit::shutdown();
}
-
-MessageLoop* WebKitThread::InitializeThread() {
- if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kSingleProcess))
- return NULL;
-
- DCHECK(!webkit_thread_.get());
- webkit_thread_.reset(new InternalWebKitThread);
- bool started = webkit_thread_->Start();
- DCHECK(started);
- return webkit_thread_->message_loop();
-}