New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 687085 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
OOO Dec 22 - Jan 8
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

media::AudioManager::Get() pattern is not self-sufficient.

Project Member Reported by olka@chromium.org, Jan 31 2017

Issue description

The global variable |g_last_created| pointing to AudioManager is 
reset in a non-thread-safe way on a thread AudioManagerDeleter is called on (https://cs.chromium.org/chromium/src/media/audio/audio_manager.cc?type=cs&l=274).

Clients access it in a non-thread way through AudioManager::Get().

The only reason the code works is the way Content manages lifetime of the browser threads and of the AudioManager. And it does NOT work if AudioManager::Get() is called on audio thread.

AudioManager is in media and should know nothing about threading of its clients. And without that context AudioManager::Get() is non-thread-safe and misleading. We should re-work it or better get rid of it.
 
Why doesn't it work if ::Get() is called on the audio thread? If the audio manager exists the audio thread does too, if it does not exist neither does the audio thread (modulo osx).

Comment 2 by olka@chromium.org, Jan 31 2017

The global pointer to AM is reset on UI thread before AM is posted for deletion to the audio thread (see AM deleter). And there can be tasks queued up on audio thread Wich will be executed after that.
AM is alive, but AM::Get() returns nullptr.
For background, crbug.com/667981 was caused by using Get on the audio manager thread.

Comment 4 by olka@chromium.org, Feb 20 2017

Issue 694197 is another example.

Comment 5 by olka@chromium.org, Jul 11 2017

Cc: alokp@chromium.org
Status: WontFix (was: Available)
AudioManager and AudioThread lifetimes were changed recently, not applicable any more.

Sign in to add a comment