Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(141)

Side by Side Diff: docs/design/startup.md

Issue 2827383002: Port sandbox, sandbox faq, and startup design docs to markdown. (Closed)
Patch Set: Fix a trivial typo Created 3 years, 8 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « docs/design/sandbox_top_diagram.png ('k') | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1 # Startup
2
3 Chrome is (mostly) shipped as a single executable that knows how to run as all
4 the interesting sorts of processes we use.
5
6 Here's an overview of how that works.
7
8 1. First there's the platform-specific entry point: `wWinMain()` on Windows,
9 `main()` on Linux. This lives in `chrome/app/chrome_exe_main_*`. On Mac and
10 Windows, that function loads modules as described later, while on Linux it
11 does very little, and all of them call into:
12 2. `ChromeMain()`, which is the place where cross-platform code that needs to
13 run in all Chrome processes lives. It lives in `chrome/app/chrome_main*`.
14 For example, here is where we call initializers for modules like logging and
15 ICU. We then examine the internal `--process-type` switch and dispatch to:
16 3. A process-type-specific main function such as `BrowserMain()` (for the outer
17 browser process) or `RendererMain()` (for a tab-specific renderer process).
18
19 ## Platform-specific entry points
20
21 ### Windows
22
23 On Windows we build the bulk of Chrome as a DLL. (XXX: why?) `wWinMain()`
24 loads `chrome.dll`, does some other random stuff (XXX: why?) and calls
25 `ChromeMain()` in the DLL.
26
27 ### Mac
28
29 Mac is also packaged as a framework and an executable, but they're linked
30 together: `main()` calls `ChromeMain()` directly. There is also a second entry
31 point, in
32 [`chrome_main_app_mode_mac.mm`](https://cs.chromium.org/chromium/src/chrome/app_ shim/chrome_main_app_mode_mac.mm),
33 for app mode shortcuts: "On Mac, one can't make shortcuts with command-line
34 arguments. Instead, we produce small app bundles which locate the Chromium
35 framework and load it, passing the appropriate
36 data." This executable also calls `ChromeMain()`.
37
38 ### Linux
39
40 On Linux due to the sandbox we launch subprocesses by repeatedly forking from a
41 helper process. This means that new subprocesses don't enter through main()
42 again, but instead resume from clones in the middle of startup. The initial
43 launch of the helper process still executes the normal startup path, so any
44 initialization that happens in `ChromeMain()` will have been run for all
45 subprocesses but they will all share the same initialization.
OLDNEW
« no previous file with comments | « docs/design/sandbox_top_diagram.png ('k') | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698