system_call: New.

1 files changed, 13 insertions, 7 deletions

diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn
index c9efd1f4..e8556a91 100644
--- a/glibc/fork.mdwn
+++ b/glibc/fork.mdwn
@@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-On [[Unix]] systems, `fork` is a rather simple system call.
+On [[Unix]] systems, `fork` is a rather simple [[system call]].
 
 Our implementation in [[glibc]] is and needs to be rather bulky.
 
@@ -22,12 +22,13 @@ which requires a small number of [[RPC]] for each of them.
 In sum, [[this affects performance|open_issues/performance/fork]] when new
 processes are continuously being spawned from the shell, for example.
 
-Often, a `fork` call will eventually be followed by an `exec`, which will in
-turn close (most of) the duplicated port rights.  Unfortunately, this cannot be
-known at the time the `fork` executing, so the code calling `fork` has to be
-modified, and the `fork`, `exec` combo be replaced by a `posix_spawn` call, for
-example, to avoid this work of duplicating each port right, then closing each
-again.
+Often, a `fork` call will eventually be followed by an `exec`, which [[may in
+turn close|open_issues/secure_file_descriptor_handling]] (most of) the
+duplicated port rights.  Unfortunately, this cannot be known at the time the
+`fork` executing, so in order to optimize this, the code calling `fork` has to
+be modified instead, and the `fork`, `exec` combo be replaced by a
+`posix_spawn` call, for example, to avoid this work of duplicating each port
+right, then closing each again.
 
 As far as we know, Cygwin has the same problem of `fork` being a nontrivial
 operation.  Perhaps we can learn from what they're been doing?  Also, perhaps
@@ -51,6 +52,11 @@ they have patches for software packages, to avoid using `fork` followed by
     ([[!taglink open_issue_glibc]]).
 
 
+## Related
+
+  * [[secure file descriptor handling]].
+
+
 # External
 
   * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by