diff options
author | jam@chromium.org <jam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-04-26 06:41:16 +0000 |
---|---|---|
committer | jam@chromium.org <jam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-04-26 06:41:16 +0000 |
commit | f0170325dafb6b27b4e0dd4491b6ff78cf9eb6ae (patch) | |
tree | 1b14bac06d71243993635f2b2f4aac0a4781176e /tools | |
parent | 57391d0577690634db7c973f2df0ae60c8e5721d (diff) | |
download | chromium_src-f0170325dafb6b27b4e0dd4491b6ff78cf9eb6ae.zip chromium_src-f0170325dafb6b27b4e0dd4491b6ff78cf9eb6ae.tar.gz chromium_src-f0170325dafb6b27b4e0dd4491b6ff78cf9eb6ae.tar.bz2 |
Move the synchronous GPU messages to the IO thread to avoid deadlock.
I patched in Jonathan's change from http://codereview.chromium.org/6881105/ for the CreateViewCommandBuffer message, and also added the Synchronize and EstablishChannel. The latter required making GpuDataManager callable from the IO thread. I moved the code that loads the blacklist from the prefs and web to Chrome code, since I wanted to do that anyways so that GpuProcessHostUIShim and GpuDataManager can move to content (I'll do that later).
Since the messages are filtered on the IO thread, it's now GpuProcessHost that creates GpuProcessHostUIShim. Accordingly, all the code that used to call GpuProcessHostUIShim to send a message now has to call GpuProcessHost, since the logic of when to create a process is there. Also, since there's no IO thread object for the in-process case, I've had to break that in the meantime. Al will take a look at that later.
BUG=77536
Review URL: http://codereview.chromium.org/6902021
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@82990 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions