summaryrefslogtreecommitdiffstats
path: root/chrome/browser/in_process_webkit/webkit_thread.cc
diff options
context:
space:
mode:
authorananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-20 22:18:45 +0000
committerananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-20 22:18:45 +0000
commit6e948a40ee9134cfba48eb6d007378a4f4c11a8d (patch)
treede4f6ec194b99f162e612462805692ba9445f35d /chrome/browser/in_process_webkit/webkit_thread.cc
parentd7fc97946625fee2c54e18bce4f61608efeeef03 (diff)
downloadchromium_src-6e948a40ee9134cfba48eb6d007378a4f4c11a8d.zip
chromium_src-6e948a40ee9134cfba48eb6d007378a4f4c11a8d.tar.gz
chromium_src-6e948a40ee9134cfba48eb6d007378a4f4c11a8d.tar.bz2
Revert 32608 - RESUBMIT of http://src.chromium.org/viewvc/chrome?view=rev&revision=32319 with unit test fixes.
Reverting this as this caused a number of valgrind test failures. Make the WebKitThread object start the WebKit thread on construction (not lazily). 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. TEST=The WebKit thread gets spun up early in the initialization process. BUG=24144 Review URL: http://codereview.chromium.org/404025 TBR=jorlow@chromium.org Review URL: http://codereview.chromium.org/427001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32687 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.cc32
1 files changed, 21 insertions, 11 deletions
diff --git a/chrome/browser/in_process_webkit/webkit_thread.cc b/chrome/browser/in_process_webkit/webkit_thread.cc
index 400242b..6311140 100644
--- a/chrome/browser/in_process_webkit/webkit_thread.cc
+++ b/chrome/browser/in_process_webkit/webkit_thread.cc
@@ -9,17 +9,9 @@
#include "chrome/common/chrome_switches.h"
#include "third_party/WebKit/WebKit/chromium/public/WebKit.h"
-// This happens on the UI thread.
+// This happens on the UI thread before the IO thread has been shut down.
WebKitThread::WebKitThread() {
- 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;
- }
-
- webkit_thread_.reset(new InternalWebKitThread);
- bool started = webkit_thread_->Start();
- DCHECK(started);
+ // 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.
@@ -31,6 +23,13 @@ WebKitThread::~WebKitThread() {
DCHECK(!ChromeThread::CurrentlyOn(ChromeThread::WEBKIT));
}
+void WebKitThread::EnsureInitialized() {
+ DCHECK(ChromeThread::CurrentlyOn(ChromeThread::IO));
+ if (webkit_thread_.get())
+ return;
+ InitializeThread();
+}
+
WebKitThread::InternalWebKitThread::InternalWebKitThread()
: ChromeThread(ChromeThread::WEBKIT) {
}
@@ -44,10 +43,21 @@ 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 UI thread any longer than we have to.
+ // them now) so we don't block the IO 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();
+}