Browser Process Shutdown
Stopping the UI Message Loop
- A UI event is received that leads to BrowserList::RemoveBrowser() (closing the window, closing the last tab, keyboard shortcut for app termination, etc), which leads to g_browser_process->ReleaseModule()
- If it's the last reference to g_browser_process, then we begin application termination.
- Note that Mac keeps the application alive even without browser windows by adding an extra g_browser_process->AddRefModule().
- The last BrowserProcessImpl::ReleaseModule() call posts a task to the message loop to exit
- Notification content::NOTIFICATION_APP_TERMINATING is broadcast
- The UI message loop eventually stops running, we exit out of RunUIMessageLoop(). Note that all other main browser threads are still running their message loops. So even though the main (UI) thread outlives all other joined browser threads, its MessageLoop terminates first.
- After exiting the UI message loop, the shutdown sequence is started in BrowserMainParts::RunMainMessageLoopParts, which calls PostMainMessageLoopRun.
- In ChromeBrowserMainParts::PostMainMessageLoopRun:
- The ProcessSingleton is released.
- MetricsService stops running and we record a successful shutdown.
- We persist Local State to disk.
- We delete g_browser_process, which:
- Deletes the ProfileManager (which deletes all the profiles and persists their state, such as Preferences)
- Joins the watchdog, IO, CACHE, PROCESS_LAUNCHER threads, in that order
- Shuts down the DownloadFileManager and SaveFileManager
- Joins the FILE thread
- Deletes the ResourceDispatcherHost which joins the WEBKIT thread
- Joins the DB thread
- The AtExitManager goes out of scope and destroys all Singletons/LazyInstances
Renderer Process Shutdown
Browser process triggers shutdown via:
- Closing a tab (explain the sequence of events from UI thread objects to the IO thread termination of a renderer process)