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

Unified Diff: docs/linux_zygote.md

Issue 1324603002: [Docs] Another round of stylistic fixes. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Created 5 years, 4 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 side-by-side diff with in-line comments
Download patch
« no previous file with comments | « docs/linux_suid_sandbox_development.md ('k') | docs/mac_build_instructions.md » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: docs/linux_zygote.md
diff --git a/docs/linux_zygote.md b/docs/linux_zygote.md
index 5c84a797d8cabb84839cf76b30467bbada31ea12..5504115d04c6d74cee567b6a860c1373165949d5 100644
--- a/docs/linux_zygote.md
+++ b/docs/linux_zygote.md
@@ -1,15 +1,36 @@
-A zygote process is one that listens for spawn requests from a master process and forks itself in response. Generally they are used because forking a process after some expensive setup has been performed can save time and share extra memory pages.
+A zygote process is one that listens for spawn requests from a master process
+and forks itself in response. Generally they are used because forking a process
+after some expensive setup has been performed can save time and share extra
+memory pages.
-On Linux, for Chromium, this is not the point, and measurements suggest that the time and memory savings are minimal or negative.
+On Linux, for Chromium, this is not the point, and measurements suggest that the
+time and memory savings are minimal or negative.
-We use it because it's the only reasonable way to keep a reference to a binary and a set of shared libraries that can be exec'ed. In the model used on Windows and Mac, renderers are exec'ed as needed from the chrome binary. However, if the chrome binary, or any of its shared libraries are updated while Chrome is running, we'll end up exec'ing the wrong version. A version _x_ browser might be talking to a version _y_ renderer. Our IPC system does not support this (and does not want to!).
+We use it because it's the only reasonable way to keep a reference to a binary
+and a set of shared libraries that can be exec'ed. In the model used on Windows
+and Mac, renderers are exec'ed as needed from the chrome binary. However, if the
+chrome binary, or any of its shared libraries are updated while Chrome is
+running, we'll end up exec'ing the wrong version. A version _x_ browser might be
+talking to a version _y_ renderer. Our IPC system does not support this (and
+does not want to!).
-So we would like to keep a reference to a binary and its shared libraries and exec from these. However, unless we are going to write our own <tt>ld.so</tt>, there's no way to do this.
+So we would like to keep a reference to a binary and its shared libraries and
+exec from these. However, unless we are going to write our own `ld.so`, there's
+no way to do this.
-Instead, we exec the prototypical renderer at the beginning of the browser execution. When we need more renderers, we signal this prototypical process (the zygote) to fork itself. The zygote is always the correct version and, by exec'ing one, we make sure the renderers have a different address space randomisation than the browser.
+Instead, we exec the prototypical renderer at the beginning of the browser
+execution. When we need more renderers, we signal this prototypical process (the
+zygote) to fork itself. The zygote is always the correct version and, by
+exec'ing one, we make sure the renderers have a different address space
+randomisation than the browser.
-The zygote process is triggered by the <tt>--type=zygote</tt> command line flag, which causes <tt>ZygoteMain</tt> (in <tt>chrome/browser/zygote_main_linux.cc</tt>) to be run. The zygote is launched from <tt>chrome/browser/zygote_host_linux.cc</tt>.
+The zygote process is triggered by the `--type=zygote` command line flag, which
+causes `ZygoteMain` (in `chrome/browser/zygote_main_linux.cc`) to be run. The
+zygote is launched from `chrome/browser/zygote_host_linux.cc`.
-Signaling the zygote for a new renderer happens in <tt>chrome/browser/child_process_launcher.cc</tt>.
+Signaling the zygote for a new renderer happens in
+`chrome/browser/child_process_launcher.cc`.
-You can use the <tt>--zygote-cmd-prefix</tt> flag to debug the zygote process. If you use <tt>--renderer-cmd-prefix</tt> then the zygote will be bypassed and renderers will be exec'ed afresh every time.
+You can use the `--zygote-cmd-prefix` flag to debug the zygote process. If you
+use `--renderer-cmd-prefix` then the zygote will be bypassed and renderers will
+be exec'ed afresh every time.
« no previous file with comments | « docs/linux_suid_sandbox_development.md ('k') | docs/mac_build_instructions.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698