diff options
author | saintlou@chromium.org <saintlou@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-04-20 17:38:26 +0000 |
---|---|---|
committer | saintlou@chromium.org <saintlou@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-04-20 17:38:26 +0000 |
commit | b2838dff7172a0c10dba127f517a5a7c081f4def (patch) | |
tree | aa536e9334056e97e13928e7a9e69c24285b1b2c /ppapi | |
parent | 8c52c8959535730fb44380d1247c388fe624dc0e (diff) | |
download | chromium_src-b2838dff7172a0c10dba127f517a5a7c081f4def.zip chromium_src-b2838dff7172a0c10dba127f517a5a7c081f4def.tar.gz chromium_src-b2838dff7172a0c10dba127f517a5a7c081f4def.tar.bz2 |
Refcount browser process in BaseLoginDisplayHost so message loop does not exit
When no browser is present - e.g. on the ChromeOS login screen -
BrowserProcessImpl::module_ref_count was 0. New message loop clients
(such as menus) could acquire and release this ref count, which would
cause the message loop and the process to exit. Some login screen
object should hold a reference on the message loop. This CL gives
that responsibility to BaseLoginDisplayHost.
Email discussion follows:
On Fri, Apr 15, 2011 at 11:55 AM, Nikita Kostylev <nkostylev@google.com> wrote:
> How about incrementing it in BaseLoginDisplayHost ctor, decrementing in
> destructor?
> chrome/browser/chromeos/login/base_login_display_host.cc
> BaseLoginDisplayHost instance is created when Chrome OS is booted
> (see base_login_display_host.cc::200) and exists till user signs in or
> starts Guest session.
> base_login_display_host.cc::101
> void BaseLoginDisplayHost::OnSessionStart() {
> MessageLoop::current()->DeleteSoon(FROM_HERE, this);
> }
> Since it's DeleteSoon, Browser will already exist when BaseLoginDisplayHost
> destructor is called.
> On Fri, Apr 15, 2011 at 10:34 PM, Mitsuru Oshima <oshima@google.com> wrote:
>>
>> +anton who may also know this.
>>
>> On Fri, Apr 15, 2011 at 11:33 AM, Roy Hashimoto <rhashimoto@google.com>
>> wrote:
>>>
>>> Any feedback on whether and how the ChromeOS login screen should hold
>>> a reference count on the message loop?
>>>
>>> Thanks,
>>> Roy
>>>
>>> On Thu, Apr 14, 2011 at 3:06 PM, Roy Hashimoto <rhashimoto@google.com>
>>> wrote:
>>> > Hi Dave -
>>> >
>>> > Oshima-san suggested that you might have an answer to an issue I'm
>>> > having with menus. In order to keep the message loop running even if
>>> > the browser exits, the MenuController class calls a ref/unref on
>>> > ViewsDelegate which calls AddRefModule/ReleaseRefModule on
>>> > g_browser_process. The problem is that when no browser is present -
>>> > e.g. on the ChromeOS login screen - that reference count is 0, so
>>> > using this menu class increments the count to 1 and decrements it to 0
>>> > and that exits the message loop and ends the process.
>>> >
>>> > It seems like some login screen class should be calling
>>> > AddRefModule/ReleaseRefModule since it is using the message loop.
>>> > Would you agree, and if you do, where should those calls be made?
>>> > It's a little tricky because we have to be sure that the transition
>>> > from login screen to browser adjusts the count in the proper order.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/6870016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@82327 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'ppapi')
0 files changed, 0 insertions, 0 deletions