Chrome is (mostly) shipped as a single executable that knows how to run as all the interesting sorts of processes we use.
Here's an overview of how that works.
main()on Linux. This lives in
chrome/app/chrome_exe_main_*. On Mac and Windows, that function loads modules as described later, while on Linux it does very little, and all of them call into:
ChromeMain(), which is the place where cross-platform code that needs to run in all Chrome processes lives. It lives in
chrome/app/chrome_main*. For example, here is where we call initializers for modules like logging and ICU. We then examine the internal
--process-typeswitch and dispatch to:
BrowserMain()(for the outer browser process) or
RendererMain()(for a tab-specific renderer process).
On Windows we build the bulk of Chrome as a DLL. (XXX: why?)
chrome.dll, does some other random stuff (XXX: why?) and calls
ChromeMain() in the DLL.
Mac is also packaged as a framework and an executable, but they‘re linked together:
ChromeMain() directly. There is also a second entry point, in
chrome_main_app_mode_mac.mm, for app mode shortcuts: "On Mac, one can’t make shortcuts with command-line arguments. Instead, we produce small app bundles which locate the Chromium framework and load it, passing the appropriate data." This executable also calls
On Linux due to the sandbox we launch subprocesses by repeatedly forking from a helper process. This means that new subprocesses don't enter through main() again, but instead resume from clones in the middle of startup. The initial launch of the helper process still executes the normal startup path, so any initialization that happens in
ChromeMain() will have been run for all subprocesses but they will all share the same initialization.