diff options
| author | scherkus@chromium.org <scherkus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-23 22:57:34 +0000 |
|---|---|---|
| committer | scherkus@chromium.org <scherkus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-23 22:57:34 +0000 |
| commit | c72d7f9099a607ed546404a04a50402a9c3eeeb6 (patch) | |
| tree | e1a2c7cdcd270b920b3af747d21e60a304ec8b15 /chrome/renderer/render_view.cc | |
| parent | bbfc015f3a2772e5d57d794ec304ff8295e88627 (diff) | |
| download | chromium_src-c72d7f9099a607ed546404a04a50402a9c3eeeb6.zip chromium_src-c72d7f9099a607ed546404a04a50402a9c3eeeb6.tar.gz chromium_src-c72d7f9099a607ed546404a04a50402a9c3eeeb6.tar.bz2 | |
Merged PipelineInternal into PipelineImpl, eliminating a ton of thread-UNsafeness and confusion.
Long story short: there's no reason to split an implementation of class between two classes. The data was being held in one class, with the other class accessing it privately without acquiring the lock. Really, really painful to debug as well.
Now we have a unified implementation of Pipeline that takes care of client API requests as well as filter interaction.
Since Pipeline is properly reference counted and there are two less objects to worry about, the crash reported in 3.0.195.1 should also be resolved.
BUG=17107,17548
TEST=pipeline tests, media player and chrome ui tests
Review URL: http://codereview.chromium.org/159246
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21464 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/renderer/render_view.cc')
0 files changed, 0 insertions, 0 deletions