summaryrefslogtreecommitdiffstats
path: root/ppapi
diff options
context:
space:
mode:
authorsaintlou@chromium.org <saintlou@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-04-20 17:38:26 +0000
committersaintlou@chromium.org <saintlou@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-04-20 17:38:26 +0000
commitb2838dff7172a0c10dba127f517a5a7c081f4def (patch)
treeaa536e9334056e97e13928e7a9e69c24285b1b2c /ppapi
parent8c52c8959535730fb44380d1247c388fe624dc0e (diff)
downloadchromium_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