summaryrefslogtreecommitdiffstats
path: root/chrome/browser/in_process_webkit/webkit_thread.h
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.h
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.h')
-rw-r--r--chrome/browser/in_process_webkit/webkit_thread.h19
1 files changed, 4 insertions, 15 deletions
diff --git a/chrome/browser/in_process_webkit/webkit_thread.h b/chrome/browser/in_process_webkit/webkit_thread.h
index 97b1856..9838730 100644
--- a/chrome/browser/in_process_webkit/webkit_thread.h
+++ b/chrome/browser/in_process_webkit/webkit_thread.h
@@ -14,20 +14,14 @@
class BrowserWebKitClientImpl;
-// This is an object that represents WebKit's "main" thread within the browser
-// process. It should be instantiated and destroyed on the UI thread
-// before/after the IO thread is created/destroyed. All other usage should be
-// on the IO thread. If the browser is being run in --single-process mode, a
-// thread will never be spun up.
+// This creates a WebKit main thread on instantiation (if not in
+// --single-process mode) on construction and kills it on deletion.
class WebKitThread {
public:
// Called from the UI thread.
WebKitThread();
~WebKitThread();
-
- // Creates the WebKit thread if it hasn't been already created. Only call
- // from the IO thread. Only do fast-path work here.
- void EnsureInitialized();
+ void Initialize();
private:
// Must be private so that we can carefully control its lifetime.
@@ -45,12 +39,7 @@ class WebKitThread {
scoped_ptr<BrowserWebKitClientImpl> webkit_client_;
};
- // Returns the WebKit thread's message loop or NULL if we're in
- // --single-process mode. Do slow-path initialization work here.
- MessageLoop* InitializeThread();
-
- // Pointer to the actual WebKitThread. NULL if not yet started. Only modify
- // from the IO thread while the WebKit thread is not running.
+ // Pointer to the actual WebKitThread.
scoped_ptr<InternalWebKitThread> webkit_thread_;
DISALLOW_COPY_AND_ASSIGN(WebKitThread);