diff options
| author | dalecurtis@google.com <dalecurtis@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-11-18 23:38:26 +0000 |
|---|---|---|
| committer | dalecurtis@google.com <dalecurtis@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-11-18 23:38:26 +0000 |
| commit | 493b1712ea5821abd3930be03df2b2b9601deb3d (patch) | |
| tree | 6667e2596e2702937d14e29f847b51d8d14ffa51 /chrome/service | |
| parent | b986432a3ae3c5619fe67f4644ce77d7a5aeb491 (diff) | |
| download | chromium_src-493b1712ea5821abd3930be03df2b2b9601deb3d.zip chromium_src-493b1712ea5821abd3930be03df2b2b9601deb3d.tar.gz chromium_src-493b1712ea5821abd3930be03df2b2b9601deb3d.tar.bz2 | |
Ensure AudioPropertyListener callbacks happen on the browser thread.
Per discussion with shess, there may be issues when issuing calls
which modify OSX's HAL state while it's in the middle of calling us
back on another thread.
Adding some print statements shows that the property callbacks are
driven by the NSApplication pump on the base thread (in this case
that's BrowserMainLoop). Creating the listeners on the audio thread
did not cause callbacks to occur on the audio thread.
As such this change simply ensures that our device notification won't
run until after the NSApplication pump completes its current cycle.
BUG=158170
TEST=device changes continue to work.
Review URL: https://codereview.chromium.org/11348081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168480 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/service')
0 files changed, 0 insertions, 0 deletions