diff options
author | chase@chromium.org <chase@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-25 22:40:12 +0000 |
---|---|---|
committer | chase@chromium.org <chase@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-25 22:40:12 +0000 |
commit | c37f3e0fce65fb28618384916deb712693bfce73 (patch) | |
tree | 3f915db21580364fb5013e3b3c2134b7800745a4 /chrome/browser/in_process_webkit/webkit_thread.cc | |
parent | d6d1774e7fe541c36489a5dbbb19ce6acfa097ad (diff) | |
download | chromium_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.cc | 31 |
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(); -} |